페더레이션 아이덴티티 및 인증
디지털 아이덴티티는 사람들이 온라인 환경을 이동할 때 자신의 고유성을 정의하는 속성들로 구성됩니다. 페더레이션 아이덴티티는 이러한 속성을 정의하는 개체와 사용하는 개체 사이에서 이루어지는 합의입니다. 사용자가 한 곳에 로그인한 후 다른 자산을 사용하기 위해 이동할 때 다시 로그인할 필요가 없는 이유도 이러한 합의가 존재하기 때문입니다.
페더레이션 아이덴티티는 일반적인 용어이기 때문에 여러 가지 다양한 유형의 회사와 플랫폼 및 프로토콜에 적용될 수 있습니다. 하지만 페더레이션 아이덴티티 제품을 제공하는 업체들은 다른 사람들도 이해하고 접근할 수 있는 기술을 사용하는 것에 동의합니다. 이처럼 서로 다른 플랫폼 사이에서 또 다시 로그인을 요구하지 않고도 서로 통신하여 공유할 수 있습니다.
페더레이션 아이덴티티 시스템은 일명 7가지 "아이덴티티의 법칙"을 토대로 합니다.
1. 사용자 제어 및 동의: 사용자가 데이터 공유 권한을 부여하며, 공유 방식을 결정할 권한을 갖고 있습니다.
2. 최소 공개: 식별 정보는 최소한으로 공유하며, 안전하게 저장하고 빠르게 삭제해야 합니다.
3. 타당한 이유: 액세스 필요성을 입증할 수 있는 사람만 접근 가능합니다.
4. 아이덴티티 통제: 아이덴티티 보호가 무엇보다 중요하며, 이를 위해 사용자에게 비공개 식별자를 할당해야 합니다. 기업들은 여러 플랫폼을 사용하는 직원을 계속 모니터링할 수 있는 뷰를 개발하는 데 서로 협력할 수 없습니다.
5. 경쟁: 우수한 성능은 경쟁에서 나오기 때문에 다수의 아이덴티티 공급업체들이 지원을 받아야 합니다.
6. 인력 통합: 실제 사람이 프로세스에 배치되어 컴퓨터 간 해킹의 위험을 줄입니다.
7. 일관성: 사용자가 여러 플랫폼에서 단순하고 일관된 환경을 경험합니다.
이러한 개념에 대한 설명을 자세히 읽어보면 페더레이션 아이덴티티에 대한 윤곽이 잡히기 시작합니다. 오늘날 사용자들은 페더레이션 아이덴티티 프로세스를 적어도 한 번 이상 경험했을 가능성이 높습니다. Google에 로그인한 후 보호 중인 정보를 확인하러 다른 웹사이트에 다시 로그인하지 않고 들어간 적이 있다면 페더레이션 아이덴티티에 대한 개념을 경험한 것입니다.
인증 페더레이션은 어떻게 실되나요?
페더레이션 아이덴티티 관리는 강력한 합의를 토대로 합니다. 아이덴티티 공급업체와 서비스 공급업체는 접속한 사람의 신원을 나타내는 속성(사용자의 위치, 전화번호 등)을 식별할 수 있는 능력을 길러야 합니다. 이러한 자격 증명이 확인된 경우에만 인증을 받아 다수의 플랫폼을 이용할 수 있습니다.
페더레이션 아이덴티티 관리에 주로 사용되는 기술은 다음과 같습니다.
- SAML(Security Assertion Markup Language)
- OAuth
- OpenID
기업은 JWT(JSON Web Token) 토큰이나 SAML 어설션과 같은 보안 토큰을 사용해 플랫폼 사이에서 액세스 권한을 전달합니다.
OAuth를 사용하는 Google의 페더레이션 아이덴티티 프로세스를 예로 들어보겠습니다. 이 시스템을 사용하기 위해 개발자가 수행해야 할 작업은 다음과 같습니다.
1. Google의 API에서 OAuth 자격 증명 가져옵니다. 클라이언트 ID, 클라이언트 보안 코드 등 Google과 회사가 모두 알고 있는 데이터를 선택합니다.
2. Google 인증 서버에서 액세스 토큰을 가져옵니다. 사용자가 웹 액세스 요청을 마치려면 Google에서 제공하는 토큰이 필요합니다.
3. 액세스 범위를 비교합니다. 사용자가 데이터에 대한 액세스 권한을 부여하면 이제 액세스 요청이 사용자가 허용하는 공유 범위와 일치하는지 비교해야 합니다.
4. API에게 토큰을 전송합니다. 사용자는 HTTP 인증 요청 헤더에 토큰이 포함되어 있으면 언제든지 액세스 권한을 얻을 수 있습니다.
사용자는 이러한 프로세스를 거의 인지하지 못합니다. 사용자가 웹사이트에 방문하면 다른 자격 증명을 통해 로그인하라는 화면이 표시됩니다. 이후 버튼을 한두 개 클릭하면 마치 마법처럼 액세스가 이루어집니다.
페더레이션 아이덴티티를 위한 정부의 역할
컴퓨터 개발자들은 스스로를 정책이나 간섭에 상관없이 자유롭게 결정할 수 있는 자율적 실체라고 여깁니다. 사실 정부는 페더레이션 아이덴티티의 운영 방식과 관리 주체에 대해 관심이 많습니다.
이러한 관심은 2004년에 제정된 Homeland Security Presidential Directive 12에서 시작되었습니다. 이때부터 전문가들은 정부 자산에 안전하게 액세스할 수 있는 자격 증명이 필요했고, 이에 따라 개발 팀들도 플랫폼과 프로그램 사이에서 빠르게 전환할 수 있는 시스템을 개발해야 했습니다. 속도도 중요하지만 안전성도 확보해야 했습니다.
2004년부터 여러 기업들이 페더레이션 아이덴티티를 위한 합의 사항과 프로토콜 및 프로그램을 개발했습니다. 하지만 아직 부족합니다.
현재 NCCoE(National Cybersecurity Center of Excellence)와 NSTIC(National Strategy for Trusted Identities in Cyberspace) 국가 프로그램 사무국이 서로 협업하여 개인정보 보호 강화 페더레이션 아이덴티티(Privacy-Enhanced Identity Federation) 프로젝트를 진행하고 있습니다. 프로젝트가 완료되면 기업들이 페더레이션 아이덴티티에 사용할 수 있는일련의 표준을 공개할 예정입니다. 공개일은 아직 결정되지 않았습니다.
페더레이션 아이덴티티의 이점
일부 기업들은 페더레이션 아이덴티티의 개념을 전혀 모른 채 보안 로그인을 도입합니다. 반면, 제품을 이런 방식으로 운영하는 것을 생각조차 못하는 기업들도 있습니다. 어떤 기업이 옳을까요?
페더레이션 아이덴티티의 이점은 다음과 같습니다.
- 비용 절감. 제품을 페더레이션하여 사용하기 때문에 SSO 솔루션을 자체적으로 개발할 필요가 없습니다.
- 효율성 향상. 직원들이 시스템에 반복해서 로그인하느라 시간을 낭비할 필요 없습니다.
- 데이터 보호. 페더레이션 솔루션은 데이터 보호 및 보안에 대한 기대치가 더 높습니다. 기업에게는 로그인 하나하나가 취약점이기 때문에 프로세스를 간소화하면 해킹 위험을 줄일 수 니다.
액세스 페더레이션에 대한 오해
액세스 페더레이션을 사용할 경우 눈에 띄는 단점은 없지만 이에 관해 몇 가지 오해가 있습니다. 이는 다음과 같습니다.
- 통제권 약화. 페더레이션 아이덴티티 관리 솔루션은 특정 규칙과 합의가 수반됩니다. 이로 인해 통제권이 약화되는 것이 아니냐고 우려하는 사람들도 있지만 실제로는 그렇지 않습니다. SSO 공급업체들이 다양한 구성 옵션을 제공하기 때문에 필요에 따라 시스템 동작을 변경할 수 있습니다.
- 잠재적 보안 위험. 인증 프로토콜이라고 해서 전적으로 안전한 것은 아닙니다. 따라서 일부 프로그램은 페더레이션을 하더라도 알려진 취약점이 존재할 수 있습니다. 그렇더라도 일반적인 표준에 따라 페더레이션된 프로그램은 여느 프로그램보다 더 안전합니다.
Google, Microsoft, Facebook, Yahoo 등 소비자에게 알려져 신뢰할 수 있는 기업들은 대부분 페더레이션 아이덴티티 개념을 사용하고 있습니다. 페더레이션 아이덴티티를 이용하는 기업이라면 안전하므로 신뢰할 수 있다고 봐도 무방합니다. 하지만 기업은 저마다 위험과 이점을 자체적으로 평가해야 합니다.
페더레이션 인증이나 SSO(Single Sign-On) 인증이 더 안전한 솔루션인지 평가할 때 Okta를 활용하는 방법을 알아보세요.
참고 자료
Average Business User Has 191 Passwords. (2017년 11월). Security.
Federated Identity Management. (2009년). David W. Chadwick.
Understanding Federated Identity. (2007년 8월). Network World.
Using OAuth 2.0 to Access Google APIs. Google Identity Platform.
Identity Federation Governance: Catalyst for the Identity Ecosystem. (2014년). Deloitte Development.
Privacy-Enhanced Identity Federation. NIST(National Institute of Standards and Technology).
Identity Federation: A Brief Introduction. (2018년 9월). Medium.
Federated Identity Management Challenges. Identity Management Institute.
Common Federated Identity Protocols: Open ID Connect vs. OAuth vs. SAML 2. Hack EDU.
Economic Tussles in Federated Identity Management. (2012년 10월). First Monday.
A Study on Threat Model for Federated Identities in Federated Identity Management System. (2010년 6월). 2010 International Symposium on Information Technology.
The Need for a Universal Approach to Identity Management. (2018년 7월). Forbes.
Federated Identity Management Systems: A Privacy-Based Characterization. (2013년 9~10월). Cornell University.
