액세스 관리 FAQ

IAM(Identity and Access Management)은 데이터 보안의 하위 부문으로 두 가지 기능으로 구성됩니다. 바로, ID 거버넌스 및 관리(Identity Governance and Administration, IGA)와 액세스 관리(Access Management, AM)입니다.

IAM은 애플리케이션 액세스 권한을 부여·요청하고(IGA) 액세스 제어(AM)를 시행하며 액세스 이벤트(Access Event, AM)에 대한 가시성을 보장하는 체계적인 프레임워크를 제공합니다.

IGA 솔루션은 ‘누가’, ‘어떤’ 애플리케이션에 액세스하는 권한을, 또는 '특별하게 액세스하는 권한'을 부여받아야 하는지, 실제로는 누가, 누구에 의해, 언제 어떤 애플리케이션에 대한 액세스 권한을 부여받았는지’라는 질문에 대한 답을 찾도록 도와줍니다. AM 솔루션은 ‘누가 언제 무엇에 액세스했으며 신원을 검증한 방법은 무엇인가’라는 질문에 답하는 데 도움이 됩니다.

IAM(Identity and Access Management) 솔루션은 IGA(ID 거버넌스 및 관리) 기능과 AM(액세스 관리) 기능으로 구성됩니다. IAM 솔루션은 애플리케이션 액세스 권한을 부여·요청하고(IGA) 액세스 제어(AM)를 시행하며 액세스 이벤트(Access Event, AM)에 대한 가시성을 보장하는 체계적인 프레임워크를 제공합니다. 대다수 조직이 IGA 및 AM 구성 요소를 별도 배포한다는 측면에서 이 분야는 단일 IAM 제품의 복합 기능이 아닌 별개의 독립형 솔루션 제품군으로 평가받고 있습니다.

액세스 관리는 사용자에게 특정 리소스에 대한 액세스 권한이 있는지 확인하고 해당 리소스에 구현한 액세스 정책을 적용하도록 지원하는 기능입니다.

액세스 관리는 IT 관리자가 정의한 액세스 정책을 기반으로 구현되며, 어떤 사용자 그룹(예: Sales, R&D, HR)이 어떤 클라우드 애플리케이션(예: Salesforce, Office 365, Jira, Taleo)에 액세스할 수 있는지와 같은 정보, 애플리케이션별로 액세스하는 데 필요한 사용자 속성 모음(예: 신뢰할 수 있는 네트워크, 비밀번호, OTP)과 같은 정보를 포함합니다.

클라우드 애플리케이션의 민감성에 따라 평가할 사용자 속성을 더 많이 또는 더 적게 액세스 정책에 포함할 수 있습니다. 이러한 속성은 위험 기반 인증 또는 컨텍스트 기반 인증을 통해 평가하며, 이는 클라우드 애플리케이션별로 정의한 여러 액세스 정책을 시행하는 핵심 요소입니다. (자세한 내용은 컨텍스트 기반 인증 정보를 참조하실 수 있습니다.)

또 다른 클라우드 액세스 관리의 핵심은 싱글 사인온인데, 이는 사용자 이름과 비밀번호 한 세트('ID')를 사용하여 모든 클라우드 애플리케이션에 로그인할 수 있는 기능입니다. (자세한 내용은 싱글 사인온 정보를 참조하실 수 있습니다.)

IDaaS는 서비스 형태의 IAM으로, 서비스 형태의 ID라고도 합니다. IDaaS는 ID 및 액세스 관리(IAM) 솔루션을 의미하는데, 이는 ID 및 액세스 관리를 위한 클라우드 기반 서비스형 배포 모델을 제공합니다. 최근 몇 년 동안은 별도의 시장으로 여겨졌지만 최근 시장 동향을 고려했을 때 향후 IDaaS는 온프레미스 설치, 소프트웨어 또는 클라우드 기반 플랫폼 배포 방법을 포함하는 ‘액세스 관리 및 IGA’라는 별도 분야 두 가지로 받아들여질 것입니다.

IGA(Identity Governance and Administration, ID 거버넌스 및 관리)는 ‘누가’, ‘어떤’ 애플리케이션에 액세스하는 권한을, 또는 '특별하게 액세스하는 권한'을 부여받아야 하는지, 실제로는 누가, 누구에 의해, 언제 어떤 애플리케이션에 대한 액세스 권한을 부여받았는지’라는 질문에 대한 답을 찾도록 도와주는 기능들을 말합니다. 예를 들어, IGA 솔루션은 R&D 직원에게 GitHub, Jira, Confluence와 같은 특정 개발 애플리케이션의 액세스 권한이 있는지 결정하는 데 도움이 될 수 있습니다. IGA 솔루션은 해당 애플리케이션의 R&D 그룹 구성원 정보를 기반으로 액세스를 자동 프로비저닝할 수 있습니다. 또한, R&D 사용자는 다른 애플리케이션에 프로비저닝된 액세스 권한을 요청할 수 있으며, 이는 일부 IGA 솔루션이 지원하는 기능인 관리자 승인 프로세스를 거치게 됩니다.

ID 연계(Identity federation)는 사용자 인증 관리를 담당하는 ‘신뢰할 수 있는 단일 ID 공급자(Identity Provider, IdP)’ 기반 아키텍처로, 사용자가 액세스를 시도할 때마다 애플리케이션이 ID 공급자에게 인증 프로세스를 중계합니다. 인증 프로세스를 신뢰할 수 있는 ID 공급자에게 중계하는 애플리케이션을 서비스 공급자(Service Provider, SP)라고 합니다.

ID 연계는 조직 내외부 어디서나 수많은 웹 애플리케이션의 자격 증명을 별도 관리하는 문제와 불편을 해소하고, 관리자와 사용자가 사용자 이름과 비밀번호 한 세트(ID)만 관리해도 다수의 애플리케이션과 IT 자원에 액세스할 수 있도록 지원합니다. ID 연계는 여러 비밀번호를 관리하는 불편함을 해소하고 보안을 향상하며 수많은 비밀번호를 다루는 데서 오는 문제를 해결합니다.

ID 연계는 SAML, Open ID Connect와 같은 페더레이션 프로토콜과 Microsoft의 WS 페더레이션 같은 독점 프로토콜을 이용합니다.

로그인 연계는 사용자가 기존 기업 ID를 사용하여 여러 애플리케이션에 로그인할 수 있도록 지원하는 페더레이션 프로토콜(SAML, Open ID Connect 등) 기능입니다. 예를 들어, 서로 다른 사용자 이름, 비밀번호 한 세트(또는 ID)를 사용하여 별개의 클라우드 애플리케이션에 로그인하는 대신, 로그인 연계 기능을 이용하면 아침에는 기업 네트워크, 밤에는 VPN 로그인에 사용하는 것과 동일한 ID로 Office 365, Salesforce, AWS 등에 로그인할 수 있습니다.

ID 공급자는 다른 독립적인 웹사이트(서비스 공급자, ‘SP’)에 액세스를 시도하는 사용자를 인증하는 시스템입니다. 서비스 공급자와 함께 ID 연계 아키텍처를 구성하는 요소로, 이 아키텍처에서 웹사이트(또는 서비스 공급자)에 액세스를 시도하는 사용자는 ID 공급자로 중계되어 인증을 진행합니다. ID 공급자는 사용자의 인증 데이터(예: 사용자의 쿠키, 장치, 네트워크, OTP)를 검증하고 ‘허용’ 또는 ‘거부’ 응답을 생성하여 서비스 공급자에게 전송합니다. 또한, 다른 독립적인 웹사이트를 대신하여 특정 데이터에 액세스하는 권한을 요청할 수 있습니다. 웹메일 계정의 이메일 주소나 소셜 네트워크 계정의 친구 이름과 같은 정보에 액세스하는 권한이 인증 데이터로 포함될 수 있습니다.

예를 들어, SafeNet 인증 서비스는 위에서 설명한 경우와 같이 사용자가 클라우드 애플리케이션에 액세스할 때 ID 공급자 역할을 맡습니다.

보안 토큰 서비스는 독립적인 타사 웹사이트(RP, Relying Party)에 액세스를 시도하는 사용자를 인증하는 시스템입니다. RP와 함께 보안 토큰 서비스 아키텍처를 구성하는 요소로, 웹사이트(RP)에 액세스하려는 사용자는 보안 토큰 서비스로 중계되어 인증을 진행합니다.

보안 토큰 서비스는 ID 공급자 모델 또는 토큰 기반 인증이라고도 합니다. STS(Security Token Service, 보안 토큰 서비스)는 ID 공급자에 해당하고 RP(Relying Party)는 서비스 공급자에 해당합니다. 그리고 SAML 어설션 교환 대신, 보안 토큰이라고 합니다. 다른 이름으로 불리지만 같은 개념입니다.

Security Assertion Markup Language, 즉 SAML(‘샘엘’로 읽음)은 독립적인 웹사이트 간에 인증 데이터를 교환하기 위한 XML 기반 공개형 표준으로, ID 연계 또는 연합 인증이라고도 하는 기능입니다.

ID 연계는 사용자가 보유한 기존 기업 ID를 클라우드로 확장 이용하여 클라우드 애플리케이션에 로그인하도록 지원하는 기능을 의미합니다. SAML을 이용하는 클라우드 앱의 연합 인증 기능을 통해 기존 기업 ID로 모든 클라우드 애플리케이션에 로그인할 수 있으므로 사용자 이름, 비밀번호 세트를 5개, 25개씩 유지 관리하는 대신, 하나만 관리할 수 있습니다.

SAML 작동 원리
사용자가 클라우드 기반 애플리케이션에 로그인을 시도하면 신뢰할 수 있는 ID 공급자로 리디렉션되어 인증을 거칩니다. ID 공급자는 사용자의 자격 증명(예: 사용자 이름과 1회용 비밀번호)을 수집하고 액세스되는 해당 클라우드 애플리케이션에 응답을 반환합니다. 이 응답을 SAML 어설션이라고 하며 SAML 어설션에는 허용, 거부 응답이 포함됩니다.

이 응답을 기반으로 Salesforce, Office 365, DropBox 등의 서비스 제공자(SP)는 애플리케이션 액세스를 차단하거나 허용합니다.

WS 페더레이션 서비스(WS-Fed)는 Microsoft의 독점 ID 연계 프로토콜입니다. WS-Fed는 Microsoft의 AD FS(Active Directory Federation Services)와 함께 작동하여 액티브 디렉터리에 저장된 ID를 Office 365나 Azure 같은 Microsoft 클라우드 애플리케이션으로 확장합니다. SAML과 마찬가지로 WS-Fed는 ID 공급자 모델을 사용합니다. Microsoft 클라우드 애플리케이션에 액세스하면 사용자가 AD FS로 리디렉션되어 인증을 거치게 되는데, 이는 사용자 액세스에 대한 클라우드 애플리케이션의 응답(허용 또는 거부)에 따릅니다.

공개 인증(Open Authorization)의 줄임말인 OAuth는 독립적인 웹사이트 간의 연계 인증, 또는 '토큰 기반' 인증 및 권한 부여 목적의 공개형 표준 인증입니다. SAML, Open ID Connect, WS-Fed와 같은 기타 ID 연계 프로토콜과 마찬가지로 OAuth를 이용하면 신뢰할 수 있는 ID 공급자가 검증한 ID로 애플리케이션에 로그인할 수 있습니다. OAuth는 연계 인증을 뛰어넘어 RP(Relying Party) 웹사이트가 사용자 이름, 이메일 주소와 같은 특정 계정 정보에 액세스하도록 승인하는 기능을 사용자에게 제공합니다. 예를 들어 OAuth는 소셜 네트워크 웹사이트에서 웹메일 연락처에 액세스하고 이들을 소셜 네트워크에 초대할 것인지 묻는 데 사용하는 프로토콜입니다.

OpenID Connect는 SAML과 마찬가지로 ID 공급자 모델을 사용하는 공개형 표준 ID 연계 프로토콜입니다. 그러나 쿠키를 사용하기 때문에 브라우저에서 열리는 애플리케이션('브라우저 기반 애플리케이션')에서만 작동하는 SAML과 달리, OpenID Connect는 싱글 사인온 프레임워크를 제공하여 브라우저 기반 애플리케이션, 기본 모바일 앱 및 데스크톱 클라이언트(예: 리치 클라이언트, 일부 VPN) 전반에 싱글 사인온 기능을 구현할 수 있습니다. 오늘날 구현된 대다수 싱글 사인온 기능은 클라우드·브라우저 기반 앱만 지원하는 반면, 더 많은 ID 공급자가 OpenID Connect를 도입함에 따라 한 번의 인증만으로도 데스크톱 클라이언트나 브라우저 기반 애플리케이션, 기본 모바일 앱 등의 모든 리소스에 동시 액세스할 수 있게 변하고 있습니다.

BYOI(Bring Your Own Identity)는 다른 곳에서 발급된 ID를 지원하여 해당 ID로 리소스에 안전하게 액세스하도록 지원할 수 있는 기업이나 조직의 역량을 설명하는 용어입니다.

ID 관리 분야에서 공급업체와 조직은 직원과 파트너사가 각자의 ID를 사용하여 기업 리소스에 액세스할 수 있도록 지원하고자 합니다. 이론적으로, 충분한 신원 보증을 제공하는 ID 모두가 이에 해당할 수 있습니다. 예를 들어, 정부 발급 신분증이나 의료 스마트카드는 물론, 온라인 ID(예: 소셜 ID, 직업 네트워크 ID 또는 FIDO처럼 상업적으로 사용 가능한 ID)가 있습니다. 기업 환경과 소비자 환경이 더욱 밀접하게 통합되면서 소비자 서비스 부문에서 일반적으로 찾아볼 수 있는 유형의 인증 방법을 동일하게 구현해야 한다는 압력이 기업 보안팀에 더해지고 있습니다.

ID 브로커는 사용자의 기존 ID(다양한 기존 ID)를 이용해 별개의 웹사이트에 인증하도록 하여 BYOI 체계를 지원할 수 있는 시스템입니다. 예를 들어, 사용자의 소셜 ID나 웹메일 ID를 지원할 수 있으며 해당 사용자가 다수의 독립적인 웹사이트에 액세스하도록 허용합니다. ID 브로커를 사용하면 조직에서 여러 ID 공급자를 지원할 수 있습니다.

SSO(Single Sign-On, 싱글 사인온)는 한 번만 인증하고 나면 다양한 리소스에 액세스할 때 자동 인증되는 기능을 제공합니다. 개별 애플리케이션이나 시스템에 별도로 로그인하고 인증할 필요가 없으므로 본질적으로는 사용자와 대상 애플리케이션 간의 중개자 역할을 맡습니다. 대상 애플리케이션과 시스템은 자체 자격 증명을 계속 유지 보관하는 한편, 사용자 시스템에 로그인 프롬프트를 표시합니다. SSO는 이러한 프롬프트에 응답하고 자격 증명을 로그인/비밀번호 한 세트에 매핑합니다. (출처: Gartner)

분리형 솔루션이든 광범위한 액세스 관리 솔루션이든 SSO는 다양한 ID 연계 프로토콜을 통해 활용할 수 있는 기능입니다. 여기에는 SAML 2.0이나 Open ID Connect와 같은 오픈소스 프로토콜, Microsoft의 WS 페더레이션과 같은 독점 프로토콜, 비밀번호 저장이나 역방향 프록시 등의 기타 기술이 포함됩니다.

비밀번호 관리자라고도 하는 비밀번호 저장소는 대상 애플리케이션이 레거시 또는 맞춤형 애플리케이션과 같은 ID 연계 프로토콜을 지원하지 않을 때 SSO(싱글 사인온) 환경을 만드는 간단한 방법입니다. 비밀번호 저장소는 다른 웹사이트의 비밀번호를 저장하고 암호화하여 작동하는 시스템입니다. 사용자는 전용 비밀번호를 사용하여 애플리케이션별로 로그인하는 대신, (비밀번호 저장소의 비밀번호를 복호화하는) 마스터 비밀번호로 간단히 인증할 수 있으므로 서로 다른 비밀번호를 관리할 필요가 없습니다.

권한 부여(Authorization)는 올바르게 인증받은 사용자가 해당 리소스의 소유자나 관리자가 정의한 대로 액세스가 허용된 리소스에만 액세스하도록 지원하는 프로세스입니다. 소비자 환경에서는 클라우드 기반 애플리케이션(예: 소셜 네트워크)이 독립적인 웹사이트(예: 사용자의 웹메일 계정)의 특정 정보에만 액세스하도록 하는 사용자를 지원하는 프로세스를 의미하기도 합니다.

인증(Authentication)은 사용자가 애플리케이션이나 서비스, 컴퓨터, 디지털 환경에 로그인할 때 제공하는 자격 증명을 기반으로 사용자의 신원을 검증하거나 식별하는 프로세스입니다. 대다수 인증의 자격 증명은 사용자가 가진 것(예: 사용자 이름)과 사용자가 알고 있는 것(예: 비밀번호)으로 구성됩니다. 사용자가 제공한 자격 증명이 기본 애플리케이션이나 ID 공급자가 저장한 자격 증명과 일치하면 성공적으로 인증이 이뤄지고 액세스 권한이 부여됩니다.

컨텍스트 기반 인증은 사용자가 애플리케이션에 로그인할 때 평가하는 여러 추가 정보를 기반으로 하는 인증 방법입니다. 가장 일반적인 유형의 컨텍스트 정보에는 사용자의 위치, 시간, IP 주소, 장치 유형, URL과 애플리케이션의 평판 정보가 포함됩니다. 위험 기반 인증 또는 적응형 인증이라고도 하는 컨텍스트 기반 인증은 최대한 투명하고 원활한 인증 절차를 구현하고자 하는 SSO 및 액세스 관리 업계의 핵심 요소입니다.

싱글 사인온 및 액세스 관리 솔루션은 컨텍스트(장치, 역할, 위치)나 동작 기반(예: 입력 속도, 페이지 보기 순서) 정보와 같은 사용자 로그인 속성을 평가함으로써 사용자에게서 필요한 인증 수준과 애플리케이션별로 정의된 액세스 정책이 항상 서로 부합하도록 지원할 수 있습니다. 이에 따라 모든 기업 리소스에 획일적으로 적용되는 일괄 규칙이 아니라 애플리케이션별 액세스 정책에 따라 가능한 한 가장 원활한 방식으로 인증을 세분화할 수 있습니다.

지속 인증은 사용자가 새 애플리케이션이나 리소스에 액세스할 때마다 지속 발생하는 인증 형태로, 단일 애플리케이션의 단일 인증에만 유효한 일회성 판단(예/아니오) 기능을 제공하는 일회성 또는 이진제 인증과 대조됩니다.

토큰이나 비밀번호, 지문을 사용하는 인증은 기본적으로 예/아니오를 판단하는 기능으로, 사용자의 신원을 확인한 시스템은 애플리케이션 액세스를 허용하거나 거부합니다.

그러나 컨텍스트 기반 인증 또는 행동 생체 인식(예: 검색 패턴, 입력 패턴, 기타 물리적 특성)과 같은 최신 기술 덕분에 인증은 더욱 지속적인 프로세스로 변화할 수 있습니다. 컨텍스트 기반 (위험 기반) 인증을 이용하면 IP 주소, 모바일 매개변수, 알려진 장치, 운영 체제 등과 같이 다양한 속성을 평가하여 애플리케이션 로그인별로 지속해서 개인 신원을 확인할 수 있습니다. 사실상 사용자도 모르게 확인하는 것이 가능합니다.

컨텍스트 기반 인증은 개인 신원을 원활하게 확인하는 다양한 방법을 제공합니다. 이는 다수의 클라우드 애플리케이션에 세분화된 액세스 제어를 적용하는 기능과 사용자 편의성 간의 균형을 맞춰주는 솔루션입니다. 그렇기 때문에 컨텍스트 기반 인증을 이용한 지속 인증 개념이 클라우드 액세스 관리의 토대라고 할 수 있습니다.