Security Framework (1EdTech 보안 프레임워크)
이 페이지는 1EdTech의 원문 페이지를 한국어로 번역한 것입니다. 최신 내용은 원문을 확인하시기 바랍니다. 공식 원문 보기
한국어 요약
개요
기관 하나가 여러 1EdTech 표준을 함께 쓰는 일은 흔하다. 명부는 OneRoster로 동기화하고, 도구는 LTI로 연결하고, 활동 데이터는 Caliper로 모은다. 그런데 표준마다 인증 및 인가 방식이 제각각이면 기관은 표준 수만큼의 보안 설계를 따로 검토하고 운영해야 한다. 게다가 이전 세대가 쓰던 방식에서는 실제로 취약점이 드러났다. Security Framework는 1EdTech의 모든 스펙이 공통으로 따라야 할 보안 패턴 한 벌을 정해, 여러 표준을 함께 도입해도 보안 요건이 한 가지 모양으로 수렴하게 한다.
기술 관점에서 이 프레임워크는 새 암호 기술을 만들지 않는다. IETF와 OpenID Foundation이 이미 발행한 표준을 골라 조합하고, 1EdTech 스펙이 그것을 어떻게 쓸지를 고정한다. 토대가 되는 것은 OAuth 2.0, JSON Web Token(JWT), OpenID Connect Core다. 예외는 특별한 상황에서만 검토된다. 2019년 5월 Final Release로 공개되었고 현재 버전은 v1.1이다.
원문이 함께 강조하는 점이 하나 있다. 이 프레임워크는 에듀테크 보안에 대한 공동 책임 접근의 한 부분이라는 것이다. 공통 패턴을 정의할 뿐, 안전한 도입은 올바른 구현, 기관의 검토, 공급사의 실무 관행, 설정, 조달 요구사항, 지속적인 위험 관리에 함께 달려 있다.
핵심 개념
- Platform · Client: 서비스를 제공하는 쪽과 호출하는 쪽. 웹 서비스 문맥에서는 서비스 제공자와 서비스 소비자에 해당한다.
- 인증(Authentication) 및 인가(Authorization): 「누구인가」와 「무엇을 할 수 있는가」. 프레임워크는 이 둘을 본래의 서비스 호출과 별도의 메시지 교환으로 처리하도록 정한다.
- Authorization Server: 인가 및 인증을 담당하는 서버. Platform과 독립된 시스템일 수도, Platform이 호스팅하는 엔드포인트일 수도 있다.
- OAuth 2.0: 접근 토큰을 발급하고 검증하는 인가 프레임워크. RFC 6749와 6750이 근거다.
- JSON Web Token(JWT): 서명 및 암호화된 형태로 정보를 담아 전달하는 토큰 형식. RFC 7515~7519, 7523이 근거다.
- OpenID Connect Core: OAuth 2.0 위에 얹힌 신원 계층. 런치 문맥에서 사용자를 식별하는 데 쓰인다.
구성 요소
프레임워크가 다루는 상황은 두 갈래다.
첫째는 웹 서비스 기반 표준이다. OneRoster가 대표적이다. 이 경우 스펙은 Client와 Platform 사이에 오갈 수 있는 서비스 호출의 집합을 기술한다. Client가 데이터를 가져오는 경우와 Platform이 데이터를 보내는 경우가 전형적이며, 이 호출이 적절한 보안 프레임워크 안에서 이루어지도록 인증 및 인가 절차를 별도의 메시지 교환으로 규정한다.
둘째는 웹 서비스 기반이 아닌 표준이다. LTI가 대표적이다. 이 경우 스펙은 Platform과 Client 사이의 메시지 집합을 기술하며, 웹 브라우저에서 런치하는 경우처럼 메시지 교환이 취약해지는 상황에서는 메시지에 서명한다. 서명에는 신원 기반 인증에서 파생된 데이터가 포함될 수 있고, 인가 및 인증 정보는 JWT 기반 메시지 서명에 담긴다.
문서는 v1.0(2019년 5월)과 v1.1(2021년 7월) 두 판이 Final Release로 공개되어 있다. 이와 별도로 보안 공지가 축적되어 있는데, OAuth 1.0a 폐기 예고, 초기 LTI 버전의 보안 갱신·폐기 일정, SHA-1 해시 알고리즘 폐기 예고, 그리고 LTI v1.0과 v1.1.1의 사이트 간 요청 위조(CSRF) 위협을 다룬 LTI Security Update v1.0이 여기에 해당한다.
작동 방식
- 기관 또는 공급사가 구현할 1EdTech 스펙을 정한다. 그 스펙이 요구하는 보안 패턴은 이 프레임워크가 정의한 집합 안에 있다.
- Platform과 Client가 신뢰 관계를 맺는다. 식별자와 키 조회 위치를 교환한다.
- 서비스 호출이 필요한 경우, Client가 Authorization Server에 서명된 요청을 보내 접근 토큰을 받는다.
- Client가 그 토큰으로 Platform의 서비스 엔드포인트를 호출한다. 토큰의 범위가 허용된 작업을 결정한다.
- 메시지 교환 방식인 경우, Platform이 인증을 확인한 뒤 서명된 JWT를 Client로 전달한다. Client는 Platform의 공개 키로 서명을 검증한다.
- 검증에 성공하면 요청이 처리된다. 같은 절차가 여러 표준에서 동일한 모양으로 반복되므로, 기관은 한 벌의 보안 검토로 여러 표준을 함께 다룰 수 있다.
국내 도입 시나리오
국내 대학이 학습 플랫폼과 외부 도구를 여러 표준으로 연동하면서 표준마다 다른 인증 방식을 검토해 온 경우, 검토 기준을 이 프레임워크로 통일할 수 있다. 도구를 추가할 때마다 처음부터 따지는 대신 프레임워크 준수 여부를 확인하는 방식으로 바뀐다.
국내 에듀테크 기업이 1EdTech 표준을 구현할 때는, 개별 표준의 요구사항보다 먼저 이 프레임워크를 읽는 편이 효율적이다. 여러 표준을 지원할 계획이라면 공통 계층을 한 번 구현해 재사용할 수 있다.
레거시 연동을 유지하는 기관이라면 보안 공지를 함께 확인해야 한다. OAuth 1.0a와 SHA-1은 폐기 예고 대상이고, LTI v1.0과 v1.1.1은 CSRF 위협이 공지된 버전이다. 다만 이 프레임워크는 공동 책임 접근의 한 부분이므로, 프레임워크 준수만으로 기관의 보안 검토를 대체할 수는 없다.
적합성 인증
Security Framework 자체의 적합성 인증 프로그램은 없다. 이 프레임워크는 제품을 개별적으로 시험해 인증하는 대상이 아니라, 각 서비스 명세가 공통으로 참조하는 보안 기반이기 때문이다. 원문이 「모든 1EdTech 서비스 기반 스펙은 이 프레임워크를 참조해야 한다」고 밝히는 대목이 그 구조를 보여 준다.
따라서 적합성 판정은 이 프레임워크를 채택한 개별 표준의 인증 절차 안에서 이루어진다. 예를 들어 LTI Advantage 적합성 시험을 통과한다는 것은 그 안에 포함된 보안 요건 — OAuth 2.0 기반 토큰 발급, JWT 서명 검증, OpenID Connect 런치 — 을 충족했다는 뜻이다. 개별 표준의 인증을 받으면 그 결과는 TrustEd Apps Directory에 등재된다.
관련 표준
- LTI: 메시지 교환 방식의 대표 사례다. LTI 1.3이 이 프레임워크의 JWT 서명과 OpenID Connect 패턴 위에 서 있으며, 원문도 LTI 1.3과 LTI Advantage를 참조 대상으로 명시한다.
- OneRoster: 웹 서비스 방식의 대표 사례다. 원문이 서비스 호출 보안을 설명할 때 예로 드는 표준이다.
- Data Privacy Rubric: 제품의 개인정보 처리 정책을 심사한다. 이 프레임워크가 기술 계층의 보안을 다룬다면, 그쪽은 정책 문서 계층을 다룬다.
- Security Practices Rubric: 공급사의 보안 실무 관행을 자기평가한다. 기술 패턴 준수와 조직의 운영 관행은 서로 다른 층이며, 둘을 함께 보아야 한다.
- Uniform ID Framework: 분산 식별자로 대상을 가리키고 검증한다. 신원과 인가를 다루는 층에서 서로 맞닿는다.
원문 자료
- 게이트웨이: https://www.1edtech.org/standards/security-framework
- Security Framework v1.1: https://www.imsglobal.org/spec/security/v1p1/
- Security Framework v1.0: https://www.imsglobal.org/spec/security/v1p0/
- LTI Security Update v1.0: https://www.imsglobal.org/spec/lti/security-update/v1p0
- OAuth 1.0a 폐기 예고
- SHA-1 해시 알고리즘 폐기 예고: https://www.imsglobal.org/security-bulletin-deprecation-notice-sha-1-hash-algorithm
- 적합성 인증 절차 일반: https://www.1edtech.org/certification/get-certified
이 요약은 1EdTech의 공개 자료를 바탕으로 1EdTech Korea가 작성했습니다. 기술적 세부사항은 원문 스펙을 기준으로 합니다.
이 페이지는 1EdTech의 원문 페이지를 한국어로 번역한 것입니다. 최신 내용은 원문을 확인하시기 바랍니다. 원문: https://www.1edtech.org/standards/security-framework
Security Framework
학생 데이터의 신뢰할 수 있는 교환
CIO, CSSO, 데이터 보호 책임자는 플랫폼과 도구 사이를 오가는 민감 정보와 개인식별정보(PII)에 관해 중대한 보안 우려를 갖고 있다. 이전 세대의 보안 프레임워크는 취약점을 드러냈다.
1EdTech 회원들은 자사 표준 전반에 1EdTech Security Framework를 채택함으로써 학생의 프라이버시와 보안을 개선하는 흐름을 이끌고 있다.
Security Framework는 에듀테크 보안에 대한 공동 책임 접근의 한 부분이다. 상호운용되는 제품을 위한 공통 보안 패턴을 정의하지만, 안전한 도입은 올바른 구현, 기관의 검토, 공급사의 실무 관행, 설정, 조달 요구사항, 지속적인 위험 관리에도 달려 있다.
1EdTech는 서비스 지향 및 메시지 교환 상호운용성 스펙을 만든다. 이러한 서비스 기반 스펙은 여러 가지 서로 다른 보안 패턴을 권고하거나 요구한다. 예를 들어 OAuth 1.0a 기반 메시지 서명의 사용이 그렇다. 현재와 최신 1EdTech 스펙은 OAuth 2.0, JSON Web Token, OpenID Connect에 기반한 현대적 보안 패턴을 사용한다. Security Framework는 모든 1EdTech 스펙이 사용해야 하는 보안 패턴의 집합을 정의한다(예외는 특별한 상황에서만 검토된다). 이 보안 패턴은 Internet Engineering Task Force(IETF)와 그 RFC 같은 다른 조직이 발행한 적절한 표준 및 스펙을 전제로 삼는다. 사용되는 핵심 표준은 다음과 같다.
- OAuth 2.0 — IETF의 RFC 6749 및 6750
- JSON Web Token — RFC 7515, 7516, 7517, 7518, 7519, 7523
- Open ID Connect Core — OpenID Foundation이 OAuth 2.0 위에 얹은 신원 계층
Security Framework를 사용하면 일관되고 호환되는 구현 요구사항이 촉진되며, 둘 이상의 1EdTech 스펙을 함께 구현할 때 도입이 단순해진다.
1EdTech가 OneRoster처럼 웹 서비스 기반 표준을 정의한 경우, 그 스펙은 서비스 소비자(또는 Client)와 서비스 제공자(Platform) 사이에서 일어날 수 있는 웹 서비스 호출의 집합을 기술한다. 전형적인 서비스 호출로는 Client가 Platform에서 데이터를 「가져오는」 경우와 Platform이 Client로 데이터를 「보내는」 경우가 있다. 많은 경우 이러한 서비스 호출은 적절한 보안 프레임워크 안에서 이루어져야 한다. 웹 서비스 방식을 쓰는 1EdTech 스펙에 대해, 오른쪽 그림이 이 보안 프레임워크를 도식으로 보여 준다.
스펙은 Client와 Platform이 정보를 교환하는 방법을 정의한다. 이 문서는 별도의 메시지 교환 집합을 사용해 「인증(Authentication)」과 「인가(Authorization)」를 달성하는 방법, 그리고 실제 대응하는 1EdTech 서비스 호출이 이 인가 및 인증 정보를 사용하는 방법을 정의한다. 인가와 인증은 「Authorization Server」를 사용하며, 이는 Platform과 독립된 시스템일 수도 있고 Platform이 호스팅하는 엔드포인트일 수도 있다.
1EdTech가 Learning Tools Interoperability(LTI)처럼 웹 서비스 기반이 아닌 표준을 정의한 경우, 그 스펙은 Platform과 Client 사이에서 일어날 수 있는 메시지의 집합을 기술한다. 메시지 교환이 취약해지는 상황(예: 웹 브라우저에서 런치하는 경우)에서는 메시지에 서명한다. 이 서명은 신원 기반 인증에서 파생된 데이터를 포함할 수 있다. 1EdTech 스펙은 Client가 Platform과 Client 사이에서 교환되는 메시지(사용자의 브라우저 기반 상호작용을 포함)를 Client 기반 경험으로 변환하는 방법을 정의한다. 이 문서는 Platform과 Client 사이의 별도 메시지 교환으로 인증과 인가를 달성하는 방법, 그리고 그 인가 및 인증 정보를 이 메시지 교환의 JWT 기반 메시지 서명에 담는 방법을 정의한다. 인가 및 인증 절차는 Authorization Server를 사용하며, 이는 Platform과 독립된 시스템일 수도 있고 Platform이 호스팅하는 엔드포인트일 수도 있다.
Security Framework는 2019년 5월에 Final Release로 공개되었다. 모든 1EdTech 서비스 기반 스펙은 LTI 1.3과 LTI Advantage 서비스를 포함해 이 프레임워크를 참조해야 한다.
공개 문서
Security Framework
- Security Framework v1.1 — Final Release (2021년 7월 19일)
- Security Framework v1.0 — Final Release (2019년 5월 15일)
보안 공지
- Deprecation Notice for OAuth 1.0a — 공지 (2020년 6월)
- Security Update and Deprecation Schedule for Early Versions of LTI — 공지 (2020년 3월)
- Security Bulletin — 공지 (2019년 7월 22일)
- LTI Security Update v1.0 — Final Release (2019년 7월 22일). LTI 이전 버전(v1.0, v1.1.1)의 잠재적 사이트 간 요청 위조(CSRF) 위협을 다룬다
- Deprecation Notice for SHA-1 Hash Algorithm — 공지 (2018년 2월)
