싱글 사인온(SSO)이란 무엇인가요? SSO의 작동 방식은 무엇인가요?

많은 사람들이 그러면 안 된다는 것을 알면서도 하고 있는 일들이 있습니다. 휴대폰에 저장된 파일이나 지갑 속 종이, 더 심한 경우 키보드 뒤에 붙여 둔 포스트잇에 사용자명과 비밀번호를 적어 두는 것입니다. 반려견 이름에 숫자 몇 개와 특수문자를 섞어 비밀번호로 쓰는 습관도 있습니다.

오늘날의 웹 세상에서 활동하려면 각 사용자는 수십 개의 계정명과 비밀번호를 어떻게든 관리해야만 합니다. 기억력이 비범한 사람이 아니라면 그 모두를 서로 다르게 설정하기는 어려울 것입니다. 대개 단순하고, 오래됐고, 누군가 마음먹고 시도하면 추측 가능한 것들을 사용하는 경우가 많습니다. 이는 예비 사이버 범죄자들을 위한 선물과도 같은 습관이지만, 그로 인한 문제 발생을 100% 예방할 수 있는 방법이 있습니다.

SSO(Single Sign-On)란 무엇인가요?

싱글 사인온 기술은 우리의 업무와 개인 생활 모두를 괴롭히는 비밀번호 문제에 대한 부분적인 해법입니다. SSO를 사용해 인증 서버에 한 번 로그인하면, 서버가 SSO 참여 애플리케이션들을 위한 검증된 자격 증명으로 사용할 수 있는 인증서를 대신 발급해 줍니다.

많은 분들이 이런 시스템을 이미 써 보셨을 가능성이 높습니다. 웹 애플리케이션을 위한 새 비밀번호를 만드는 대신 'Apple로 로그인', 또는 Google과 같은 다른 대기업의 ID 관리 시스템을 선택했다면 이미 SSO를 사용해 보신 것입니다. 기업 내에서도 SSO 사용이 늘고 있습니다. 기업용 SSO는 다른 인증 기술들과 결합해 수십, 수백 개 애플리케이션 및 서비스 전반의 시스템 보안을 강화하고 원활한 비밀번호 관리를 지원합니다.

핵심 요점

• SSO는 개인이 수많은 비밀번호와 사용자명의 조합을 외워야만 하는 부담을 덜어 줍니다.
• SSO를 사용하면 조직 전체가 사용하는 단 하나의 인증 시스템만 관리하면 되므로 IT 팀의 작업이 더 편해집니다.
• 또한 SSO는 애플리케이션이 네트워크 연결 관리, 소프트웨어 업데이트 확인 등 애플리케이션 운영에 필요한 서비스에 대한 사용자 인증을 수행할 수 있도록 지원합니다.

SSO 알아보기

SSO의 개념은 간단합니다. 사용하는 애플리케이션마다 사용자명과 비밀번호를 입력하거나 다른 방법으로 자신을 증명하는 대신, 인증 서버에 단 한 번만 자신에 대한 정보를 제공하면 됩니다. 한 차례 인증이 완료되면 SSO에 참여하는 애플리케이션에 접근할 때마다 인증 서버가 대신 신원 증명서를 전송합니다.

SSO는 외워 두어야 할 사용자명과 비밀번호의 개수를 줄여 줍니다. 또한 자격 증명 입력 요청 횟수를 크게 줄여 광범위한 애플리케이션들의 사용을 쉽게 만들어주고, 더 강한 비밀번호를 작성할 가능성을 높여 줍니다. 기업의 IT 기획자 관점에서 볼 때 SSO는 보안 절차 업데이트를 용이하게 만들어주고, 고급 인증 메커니즘을 인증 서버에 배포해 참여 애플리케이션들을 수정하지 않고도 더 안전한 인증 체계를 구축할 수 있도록 해 줍니다.

각 앱마다 새 계정과 비밀번호를 만드는 대신 대형 공급업체의 인증 시스템을 사용하면 개인 생활에도 여러 이점이 있습니다. 연합 ID 관리 서비스를 제공하는 대형 공급업체의 큰 장점은 고객이 맡긴 비밀번호와 개인정보 보호에 능숙하다는 것입니다. 새로운 애플리케이션을 제공하는 신규 공급업체는 여러분의 자격 증명을 그만큼 잘 보호하지 못할 수 있습니다.

SSO의 작동 방식은 무엇인가요?

SSO는 사용자가 개별 애플리케이션이 아닌 SSO 서버에 자신을 인증하도록 하는 방식으로 작동합니다. 인증이 완료되면, 인증된 사용자가 접근하고자 하는 애플리케이션에 SSO 서버가 인증서를 제공합니다. 인증서는 사용자의 신원을 검증하는 역할을 합니다.

인증서는 일반적으로 일정 기간만 유효하며, 보통 사용자가 인증을 수행한 시스템에 귀속됩니다. SSO에 참여하려면 애플리케이션이 해당 서비스를 사용하도록 작성되어야 합니다. 기업에서 SSO를 사용할 때는 IT 기획자가 하나의 SSO 모델을 선택하고, 다른 애플리케이션들이 이를 사용해 직원들의 신원을 검증하도록 요구하는 것이 일반적입니다. 자체적인 사용자 자격 증명 저장소를 만들거나, 일반적인 SSO 아키텍처를 지원하지 않는 구형 모놀리식 애플리케이션의 경우 사용이 어려울 수 있습니다.

일반적인 SSO 구성 유형

일반적인 SSO 구성 요소 및 개념으로는 중앙화된 ID 관리, 표준화, 강력한 보안 조치 등이 있습니다. 그 핵심 중 하나는 상호운용성입니다. 인증 프로세스가 사용자 친화적이고 여러 애플리케이션 전반에서 원활히 작동하려면 서로 다른 시스템들이 함께 작동해야 합니다. 상호운용성을 확보한 IT 팀은 반발을 최소화하면서 더 안전한 비밀번호와 2단계 인증 사용을 의무화할 수 있습니다.

• SAML. Security Assertion Markup Language(SAML)는 애플리케이션에 대한 사용자 인증에 쓰일 문서 구조를 정의하는 기술 사양입니다. SAML은 광범위하게 채택된 XML 표준을 사용해 ID 서버(ID 제공자)가 생성하고 애플리케이션들에 전송하는 문서의 구조를 규정합니다. 전송 대상 애플리케이션들은 SSO 용어로 '서비스 제공자'로 불리는 경우가 많습니다. SAML을 사용하는 모든 ID 제공자는 SAML을 인식하는 모든 애플리케이션에서 사용할 수 있는 인증 자격을 생성하므로 SAML은 인터넷 애플리케이션에 적합한 선택입니다.

  SAML은 애플리케이션이 수신하는 인증 정보가 변경되지 않았음을 보장하는 메커니즘을 제공하지 않습니다. 이는 다른 기술이 담당합니다.

• Kerberos. Kerberos는 1980년대 후반 MIT의 Project Athena의 일환으로 만들어진 완전한 인증, 인가 아키텍처입니다. Project Athena는 캠퍼스 전역에서 MIT 학생들이 보편적으로 접근 가능한 컴퓨터 자원 네트워크를 구축하고자 했습니다. Kerberos는 인증 서버와 애플리케이션 간 메시지 암호화에 Data Encryption Standard(DES)를 사용했었습니다. 48비트 대칭 키를 사용했으며, 암호화와 복호화에 같은 키를 사용했습니다. 당시 DES는 National Institute of Standards and Technology(NIST)의 표준 가운데 가장 안전한 암호 방식이었습니다.

  현재 Kerberos는 NIST 암호 표준에서 DES를 대체한 Advanced Encryption Standard(AES)를 사용합니다. AES는 최대 256비트의 더 긴 키를 지정하고, 다중 라운드 암호화를 허용해 시스템 공격을 매우 어렵게 만듭니다.

  Kerberos는 대칭 키 암호화를 사용하므로 신뢰할 수 있는 제3자가 키를 관리해야 하며, 사용 도메인을 엄격히 설정할 수 있고 보통 기업의 LAN과 VPN으로 사용 범위가 한정되는 엔터프라이즈 애플리케이션에 가장 적합합니다. Kerberos는 다른 인증 표준(공개 키 암호화)을 사용하여 프로세스를 시작함으로써 도메인이 설정되지 않는 인터넷에서도 사용할 수 있지만, 이러한 방식으로는 거의 사용되지 않습니다. Kerberos는 자체 인증서 형식을 사용하거나 SAML을 사용하도록 구성할 수 있습니다. Kerberos는 Microsoft를 비롯한 여러 기업들에 의해 여전히 널리 쓰이고 있습니다. 해당 기업들은 자사의 네트워크에 보안성이 낮은 NTLM 대신 Kerberos를 기본으로 사용합니다.

• OAuth. 인증 프레임워크가 포함되어 있지 않은 개방형 인가 프레임워크인 OAuth는 인터넷 애플리케이션이 보호된 서비스의 리소스에 사용자를 대신해 접근해야 하는 경우 사용하는 기본 시스템입니다. Oracle Cloud Infrastructure(OCI) 를 포함한 대부분의 클라우드 공급업체는 클라우드 리소스 접근 관리에 OAuth를 사용합니다. 또한 Oracle은 개발자가 OAuth를 사용하는 애플리케이션을 쉽게 만들 수 있도록 지원하는 라이브러리와 서비스를 제공합니다.

  OAuth 시스템의 핵심 구성 요소는 다음과 같습니다.

  • 클라이언트 시스템 : 인터넷의 다양한 서비스 리소스에 접근하고자 하는 최종 사용자 애플리케이션인 경우가 일반적입니다.
  • 인가 서버 : 클라이언트가 보호된 서비스에 접근할 수 있도록 허용하는 토큰 요청을 수신합니다. 인가 서버는 클라이언트의 인증서와 토큰 요청을 함께 수신합니다. 그리고 리소스 소유자가 승인한 액세스 토큰을 발급합니다.
  • 리소스 서버 : 클라이언트가 사용하고자 하는 정보나 서비스를 보유한 서버입니다. 리소스 서버는 클라이언트로부터 유효한 액세스 토큰을 수신하면 데이터나 서비스를 제공합니다.

  액세스 토큰에는 다양한 액세스 부여 유형을 지정할 수 있습니다. 유형은 요구되는 신뢰도 수준, 클라이언트 기기의 특성에 따라 발급됩니다. 예를 들어 스마트 TV는 노트북과 다른 액세스를 부여받을 수 있습니다.

• OpenID Connect(OIDC). OpenID Connect는 OAuth와 함께 사용하도록 만들어진 ID 관리 시스템입니다. OIDC와 OAuth는 웹 기반 애플리케이션과 모바일 애플리케이션 같은 인터넷 네이티브 시스템을 위한 완전한 SSO 환경을 제공합니다. OIDC는 자격 정보 반환의 기반으로 SAML 대신 하단에 설명된 JSON Web Token과 RESTful 프로토콜을 사용합니다. 둘 다 인터넷 네이티브이며, 개발자가 사용하기 쉽습니다.

  OIDC는 Kerberos처럼 대칭 키 암호화를 사용하지 않고 인터넷 같은 도메인리스 네트워크에 더 적합한 공개 키 암호화를 사용합니다.

• 스마트 카드 인증. OIDC 같은 시스템은 인증 도중 및 이후에 의도된 수신자만 ID 관리 제공자와 교환한 데이터를 볼 수 있도록 공개 키 암호화를 사용합니다. 공개 키 암호화는 비대칭이며, 클라이언트나 서버로 보낼 메시지를 암호화하는 공개 키와 메시지 복호화에 필수적인 비밀 개인 키를 사용합니다.

  일반적으로 개인 키는 사용자의 기기에 저장됩니다. 대부분의 노트북에는 시스템을 위한 메시지 복호화에 Trusted Platform Module(TPM)을 사용하는 변조 방지 칩이 탑재되어 있습니다. Apple과 Android 폰은 서로 다르지만 유사한 시스템을 사용합니다. Apple의 시스템은 Secure Enclave, Android의 시스템은 Android Knox라고 합니다. 해당 기술들은 기기가 적합한 요청을 발송한 시스템에 공개 키를 제공하고, 절대 노출되지 않는 개인 키로 수신 메시지를 복호화하도록 합니다.

  이러한 시스템의 장점은 기기 사용자가 암호화 처리 방식에 대해 알 필요가 없다는 점입니다. 단점은 사용자의 각 기기에 고유한 공개/개인 키 쌍이 부여되므로, 암호화 과정에서 기기가 식별된다는 점입니다. 노트북이나 전화기가 분실, 도난된 경우 도둑이 소유자의 비밀번호를 알고 있다면 암호화 시스템이 접근을 막아주지 못합니다.

  신용카드에 내장된 칩과 유사한 칩이 있는 스마트 카드를 사용하면, 사용하는 기기와 관계없이 하나의 키 세트로 인증할 수 있습니다. 카드의 칩은 자체 마이크로프로세서이므로, 카드 리더기에 삽입하거나, 근거리 통신과 같은 RFID 기술로 활성화하고 전력을 공급해야 합니다. 스마트 카드 보안은 TPM 칩이 제공하는 보안과 유사합니다.

• 엔터프라이즈 SSO. 복잡한 애플리케이션 인프라를 보유한 대기업은 자사의 네트워크 범위 내로 제한되는 엔터프라이즈 SSO 또는 eSSO 시스템을 구축할 수 있습니다. 직원들은 업무에 필요한 앱에 액세스하기 위해 한두 개의 비밀번호와 사용자명만 기억하면 되므로 편리하고, 기업은 개선되고 관리 가능한 시스템 및 데이터 보안이라는 이점을 누릴 수 있습니다. 이러한 eSSO 시스템 개발자들은 키 폐기가 용이한 대칭 키 암호화 및 그 형식이 잘 알려져 있는 SAML을 선호할 수 있으며, 엔드포인트 보안성을 높이기 위해 다양한 다중요소 인증을 활용합니다.

  SaaS 애플리케이션이 보편화됨에 따라 기업들은 인터넷에서 더 일반적으로 사용되는 OAuth 등의 시스템으로 전환하거나, 자사가 선택한 eSSO 프레임워크에 SaaS 애플리케이션을 맞추는 방식을 선택적으로 사용할 수 있습니다. SAML은 엔터프라이즈 네트워크 및 인터넷을 통해 사용 가능합니다. SaaS 애플리케이션은 사용자 인증에 두 프레임워크를 모두 지원하는 경우가 많습니다.

• 웹 SSO. 웹 애플리케이션의 경우 사용자 활동 인가에는 OAuth, 사용자 인증에는 OpenID Connect를 사용하는 것이 적합하거나 아예 해당 방식들로만 제한되는 경우가 많습니다. 인터넷을 전송 계층으로 전제하고 개발되는 웹 SSO 시스템의 구성 요소들은 IETF 표준으로 정의되고 웹 개발자들이 예상하고 선호하는 방식으로 동작하는 경향이 있습니다. 또한 인증이 인가와 긴밀히 결합되고, REST 프로토콜 같은 액세스 방식과 JSON 기반 정보 표준을 사용해 완전하고 확장 가능한 시스템을 구성합니다. 웹 SSO 시스템은 다양한 도메인을 넘나들며 대규모로 작동할 수 있도록 설계되었습니다.

• LDAP. Lightweight Directory Access Protocol(LDAP)은 사용자가 로컬 네트워크에서 사용하고자 하는 서버, 프린터 같은 리소스를 찾기 위해 1990년대에 개발된 기술입니다. LDAP는 도메인 내 모든 리소스를 파악하고 있는 인가용 서버에 사용됩니다. 따라서 인터넷 사용에는 적합하지 않습니다.

  LDAP는 네트워크 리소스에 대한 액세스 권한을 부여하는 데 사용되므로 LDAP 서버에 사용자 자격 증명을 저장하는 사용자 인증 시스템이 필요합니다. LDAP의 사용자 인증 메커니즘은 강력하지 않습니다. 예를 들어, 비밀번호를 네트워크에 평문으로 전송합니다. 암호화는 SSL/TLS 같은 다른 프로토콜이 제공할 수 있습니다.

  기업은 유연하고 확장 가능한 LDAP를 활용해 직원들의 조직 내 역할 및 그룹 멤버십 등의 추가 정보, 사무실 위치 및 전화번호 등의 속성을 저장할 수 있습니다. 그러나 기업에서는 더 세분화된 액세스 권한 관리가 필요한 경우가 많습니다. 예를 들어, 특정 데이터에 액세스할 수 있는 인물에 대한 정보 등을 고려해야 합니다. 이러한 액세스 권한은 LDAP로 쉽게 관리할 수 없습니다.

• JWT. JSON Web Token은 당사자 간에 정보를 구조화된 방식으로 안전하게 전송하는 컴팩트한 문서입니다. SAML 문서와 같은 요구 사항을 충족하지만 형식이 더 간결하므로 URL에 포함시키기 적합합니다. JWT에는 공개 키 암호화 기법을 사용한 암호학적 서명이 적용되어 신뢰성이 보장됩니다. Open Authentication(OAuth)에서는 사용자가 인증되면 ID 서버가 JSON ID 토큰을 반환합니다.

  보호된 리소스에 액세스하기 위한 인가 요청은 JSON 액세스 토큰을 반환하며, 이후 리소스 서버에 대한 모든 요청에는 해당 토큰이 포함되어야만 합니다. 이러한 트랜잭션은 매 요청마다 클라이언트의 상태(본 사례의 경우 인증 및 인가된 상태)를 함께 전달하므로, 소위 RESTful한 교환이 됩니다. REST(representational state transfer)는 리소스 서버가 리소스 사용을 원하는 모든 클라이언트들과 일일이 세션을 설정하고 유지할 필요가 없다는 점에서 유리합니다.

  JWT는 평문 문서이므로 HTTPS로 암호화된 연결에서 사용해야 합니다. 토큰은 일반적으로 개인정보 등 민감한 데이터를 포함하지 않도록 설계됩니다. 각 토큰은 공개 키 인증서 포맷에 대한 국제 표준인 X.509에 따라 서명되므로, 리소스 서버는 해당 서명을 검증해 토큰이 변조되지 않았음을 확인합니다. JWT는 OAuth/OpenID 인증 및 인가 시스템의 구성 요소입니다. 웹 애플리케이션에서 사용하도록 설계되었고, 확장성이 좋으며, 도메인 간 사용을 지원합니다.

SSO의 이점

IT 및 보안 담당자들은 대체로 SSO를 선호합니다. 사용자 인증의 중앙화, 잠재적 민감 정보 보호, 엔터프라이즈 시스템 및 애플리케이션과의 통합 관리 등을 지원하기 때문입니다. SSO에 필요한 사용자 교육, 지속적인 모니터링 및 유지보수를 수행하는 데도 대체로 긍정적입니다. 담당자들이 그와 같이 SSO 기술을 선호하도록 만드는 SSO의 중요한 이점은 다음과 같습니다.

• 중앙화된 액세스. SSO 시스템은 대부분의 기업과 인터넷 클라우드 공급업체가 운영하는 수많은 애플리케이션에 대한 사용자 계정 및 액세스 관리 부담을 경감시켜 줍니다. 모든 애플리케이션에 대한 사용자 액세스를 한 곳에서 부여하고 회수할 수 있습니다. 예를 들어, 직원이 퇴사할 때 각 애플리케이션에서 자격 증명을 개별적으로 제거할 필요가 없습니다. 보안 담당자도 각 애플리케이션을 일일이 수정할 필요 없이 한 곳에서 인증 시스템 변경을 적용할 수 있습니다.
• 보안성 향상. SSO는 직원이 기억해야 하는 사용자명과 비밀번호 조합의 수를 크게 줄입니다. 계정 관련 부담이 줄어들면, 특히 기업의 경우 다중 요소 인증과 강력한 비밀번호 정책으로 인증 보안을 강화하기 수월해집니다.
• 직원 생산성 강화. SSO가 도입되면 직원은 사용자명과 비밀번호를 기억하는 데 어려움을 덜 겪습니다. 한 번 인증되면 대개 재인증 없이 애플리케이션에 액세스할 수 있습니다. 따라서 SSO는 직원이 목표하는 작업에 더 빨리 도달하도록 돕습니다. 구현 방식에 따라 사용하는 애플리케이션별로 별도의 인증이 필요할 수도 있지만, 그러한 경우에도 동일한 SSO 자격 증명만 기억하면 됩니다.
• 비밀번호 피로 감소. 수십 개의 사용자명과 비밀번호 조합을 직접 관리하고 싶은 사람은 없을 것입니다. 기억하기 어려운 복잡한 비밀번호를 자주 변경까지 해야 한다면, 이는 직원의 사기 저하, 추측하기 쉬운 비밀번호 사용, 여러 계정에서의 비밀번호 재사용, 포스트잇에 적어두는 식의 방만한 관리 등으로 이어질 수 있습니다. SSO는 이러한 부담을 덜어줍니다.
• 규제 준수. SSO는 좀 전에 설명한 중앙화된 액세스 관리의 이점을 활용해 규제 준수를 더 수월하게 만들어 줍니다. 점검해야 할 SSO 프레임워크가 하나이므로, 감사 및 시정 조치도 간소화됩니다.
• 간편한 통합. 일반적인 기업은 여러 데이터베이스 인스턴스에 저장된 페타바이트급 데이터를 관리합니다. 제조 데이터용 데이터베이스, 공급망 데이터용 데이터베이스, 금융, 마케팅, 영업 데이터용 데이터베이스 등으로 나뉘어 있는 상황을 떠올리기 어렵지 않습니다. 영업 담당자가 재고 데이터에 접근할 수 있다면 큰 도움이 될 것이라는 사실도 쉽게 이해할 수 있습니다. CRM 시스템을 통해 재고 데이터에 접근할 수 있지만, 각 영업사원은 CRM 시스템뿐 아니라 재고 관리 데이터베이스에도 등록되어 있어야 합니다. SSO는 리소스 요청자의 검증된 신원을 제공할 수 있으며, 액세스 토큰은 각 역할별로 어떤 데이터를 볼 수 있는지를 결정하는 데 도움이 됩니다. SSO가 없다면 CRM과 재고 시스템 간 통합의 구축과 관리가 훨씬 어려워지고, 사용자들이 추가 인증 단계를 거쳐야 하거나 재고 데이터 보안이 약해질 수 있습니다.
• 간소화된 사용자 경험. 엔터프라이즈 애플리케이션과 웹 애플리케이션에 필요한 인증을 줄이면 일반적으로 사용자 경험이 향상됩니다. 많은 이들이 개인적인 온라인 서비스 사용을 통해 SSO에 이미 익숙해진 상태이므로 추가 교육이 거의 필요하지 않은 경우가 많습니다.

SSO와 보안 : SSO는 안전한가요?

우선 그 어떤 기술도 '완전히 안전'하지는 않습니다. 보안 수준이 달라질 뿐입니다. 그럼에도 상용 SSO 프레임워크는 대체로 매우 높은 보안성을 제공합니다. 이는 SSO 기술을 사용하는 주된 요인 중 하나입니다. 일반적으로 SSO 시스템 하나만으로 완전히 안전한 보안 솔루션을 구축할 수는 없습니다. 그보다는 안전한 환경을 구성하는 중요한 구성 요소라고 보는 편이 좋습니다. 사용자 인증을 수행하고 애플리케이션 및 기타 리소스 제공 시스템에 인증 자격 증명을 제공하는 SSO의 역할은 보안 전략 전반을 지탱하는 핵심 요소입니다.

SSO와 프라이버시

SSO는 더 나은 프라이버시를 지원하지만, 프라이버시의 수준은 구현 방식에 따라 달라질 수 있습니다. 예를 들어, SAML과 JWT 응답에는 인증에 대한 어설션(assertion)이 반드시 포함됩니다. 또한 사용자에게 적용되는 그룹 및 역할 등의 정보, 구현자가 제공하기로 선택한 다른 데이터 등이 포함될 수 있습니다.

웹 기반 리테일 스토어 또는 소셜 미디어 애플리케이션의 경우 사용자별 나이, 위치 등의 개인정보가 유용할 수 있습니다. 일반적으로 Facebook에 그런 개인정보를 제공한다면, 개인정보 처리방침에 해당 정보를 다른 곳에 제공하지 않는다고 명시되어 있거나, 앱이 사용자가 원하지 않는 정보는 공유하지 않을 수 있는 설정을 지원하지 않는 한, Facebook이 해당 정보를 다른 곳에 제공할 수 있다고 가정해야 합니다.

기업 환경에서는 SSO 시스템이 인증 어설션과 사용자의 조직 내 역할 정보를 함께 반환해야 합니다. 사용자가 근무하는 사무소 위치와 업무용 전화번호 정보를 함께 제공하는 것도 유용할 수 있습니다. 그 외 정보는 접근을 더 어렵게 해야 합니다. 기본 제공 범위는 보통 HR 정책에 의해 결정됩니다.

SSO 사용 사례

SSO는 하나의 로그인 자격 증명으로 여러 애플리케이션과 시스템에 대한 원활한 액세스를 제공하도록 설계되었습니다. 엄격한 규제 준수 요구 사항이 있는 조직은 추가적인 보안 조치를 구현해야 할 수도 있지만 SSO의 사용 사례는 다양합니다. 그 예시는 다음과 같습니다.

• 기업용 애플리케이션. 기업은 보통 수십에서 수백 개의 애플리케이션을 관리하며, 각 애플리케이션은 사용자 인증을 요구합니다. 애플리케이션별로 ID 관리 시스템을 구축하고 유지하는 것은 사용자나 IT 팀 모두에게 비현실적인 일입니다. SSO는 직원의 신원을 한 번만 인증하고, 그 인증을 바탕으로 리소스 사용 권한을 관리하는 방법을 제공합니다.

  인증 어설션은 일반적으로 일정 시간, 하나의 시스템에서만 유효합니다. 회사 내 각 직원의 역할에 대한 보다 세부적인 세부 정보는 SSO 시스템에서 보관하고, 애플리케이션 또는 인가 시스템이 이를 사용해 애플리케이션, 데이터, 기타 리소스에 제한적 액세스를 제공할 수 있습니다.

• 클라우드 기반 애플리케이션. 클라우드 기반 시스템의 인증 및 인가 요구사항은 비즈니스 및 소비자 환경 양쪽 모두에서 엔터프라이즈용 SSO 시스템과는 다릅니다. 소비자 환경에서는 사용 편의상 한 번 인증하면 해당 기기에서 지속적으로 서비스를 사용할 수 있도록 하는 경우가 많습니다. 예를 들어 Gmail에 로그인하면 재인증 없이 Docs나 Sheets 같은 다른 Google 애플리케이션을 사용할 수 있습니다. 비즈니스 환경에서도 SaaS, PaaS, IaaS 등을 제공하는 클라우드 서비스 공급업체는 사용자의 신원이 확인되면 광범위한 서비스 접근을 허용합니다. 인증은 단 한 번의 로그인으로 광범위한 서비스들을 사용할 수 있는 더 큰 인가 체계의 첫 단계입니다. 서비스 접근 권한은 애플리케이션별 사용자 역할에 따라 달라집니다. 한 앱에서는 관리자, 다른 앱에서는 개발자, 또 다른 앱에서는 일반 사용자일 수 있습니다. 접근 범위는 개인이 속한 조직이 구매한 서비스 범위에 의해서도 좌우됩니다.

SSO 구현

사내 보안 전문성이 부족하다는 이유로 SSO 도입을 주저하지 마세요. 관리형 보안 서비스 제공업체와 SSO 업체의 구현팀이 SSO 도입을 도와드릴 수 있습니다. 많은 기업들이 서드파티 업체가 제공하는 SSO 서비스를 사용하고 있습니다. 해당 기업들은 서드파티 업체가 제공하는 전문성, 고급 보안 기능, 확장성의 이점을 누릴 수 있으며, 해당 기업의 IT 팀은 SSO 관리를 전문가에게 맡기고 자사의 비즈니스 성장을 돕는 일에 집중할 수 있습니다.

큰 틀에서 SSO 구현을 위해서는 세 가지 요소가 필요합니다.

1. 사용자명 및 비밀번호와 같은 최종 사용자 입력을 안전하게 수집할 클라이언트 인증 시스템을 선택해 배포합니다. 엔터프라이즈 환경에서도 이러한 시스템은 대개 웹 페이지 형태로 제공되므로 인증 절차의 기기 간 일관성을 유지하기 쉽습니다. 일반적으로 기업 환경에서는 사용자가 사내 네트워크를 사용하거나 VPN을 통해 접속해야 합니다. 이러한 요구사항을 통해 기업은 믿을 수 있는 단일 ID 관리 시스템을 구축할 수 있습니다.
2. 사용자를 인증하고 조직을 대신해 인증서를 발급할 ID 관리 시스템을 구축합니다. 대부분의 환경에서 ID 관리 시스템은 사용자에게 부여된 앱 사용 권한 정보가 담긴 인가 토큰을 애플리케이션에 제공하는 시스템의 일부이거나, 인가 서버와 긴밀히 연동되어 있습니다.
3. 애플리케이션이 자체 사용자 ID 시스템을 유지하는 대신, SSO 및 인가 시스템의 인증서와 토큰을 사용하도록 구성 또는 수정합니다.

SSO 모범 사례

사내에서 직접 구현하든, 서드파티의 도움을 받든, 서비스형 모델을 선택하든 성공적인 SSO 구현을 위한 핵심 요소들이 있습니다. 그 목록은 다음과 같습니다.

1. 다중 요소 인증(MFA) 의무화. SSO를 사용하면 단일 프레임워크에서 비밀번호 정책을 강제할 수 있듯, 다중 요소 인증이라는 더 강력한 식별 기술도 도입할 수 있습니다. 관련 인증 요소로는 스마트 카드, 스마트폰 앱, 다양한 형태의 생체 인증 등이 있습니다.
2. 역할 기반 액세스 제어(RBAC) 사용. 사용자 인증을 통해서는 엔터프라이즈 리소스 액세스 관리 문제 중 일부만 해결할 수 있습니다. 또 다른 도전 과제는 사용자가 자신에게 허용된 리소스에만 액세스할 수 있도록 제한하는 것입니다. 마케팅, 재무, 제조, 영업 등의 그룹을 정의하고, 그룹 내 구성원 역할을 설정하면 액세스 제어를 더욱 세밀화하고 관리를 중앙화할 수 있습니다.
3. 표준 감사 및 업데이트. 인증 메커니즘을 단일 프레임워크로 통합하면 감사 및 새로운 표준을 준수하기 위한 업데이트 작업이 크게 단순해집니다.
4. 역할 및 권한 관리 구현. SSO는 제로 트러스트 원칙에 잘 부합합니다. 사용자는 자신의 역할에 명시적으로 필요한 리소스에만 접근할 수 있고, 명시적으로 권한이 부여된 데이터만 볼 수 있습니다.
5. 데이터 프라이버시 법규 준수. SSO 프레임워크 자체가 데이터 프라이버시 법규 준수를 보장하지는 않지만, 준수 및 증빙을 훨씬 쉽게 만들어 줍니다.

Oracle 솔루션을 활용한 안전하고 손쉬운 액세스 관리

Oracle Cloud Infrastructure(OCI)와 클라우드 및 온프레미스 애플리케이션 전반의 사용자 ID와 액세스를 관리해야 하나요? Oracle Cloud Infrastructure Identity and Access Management(IAM)가 제로 트러스트 보안 전략을 추구하는 기업에 필요한 관리 및 통합 도구를 제공합니다.

다중 요소 인증을 지원하는 범용 인증 도구를 배포하는 데 관심이 있으신가요? Oracle Access Management는 온프레미스와 클라우드에서 모두 실행 가능한 유연한 시스템을 제공합니다. 기업은 정책이 기기 및 위치와는 상관없이 사용자를 따라가도록 설정함으로써 언제 어디서든, 모든 기기를 통한 안전한 데이터 액세스를 구현할 수 있습니다. Oracle의 IAM 포트폴리오는 MFA와 함께 신뢰 디바이스 SSO 및 애플리케이션 SSO를 지원합니다. 모두 제로 트러스트 아키텍처 원칙과 요건을 달성하기 위해 필요한 요소입니다.

기업이 사용하는 애플리케이션이 갈수록 많아지고, 애플리케이션이 작업을 위해 더 많은 서비스와 데이터 소스에 의존할수록 사용자 인증과 인가 관리는 더 어려워집니다. SSO 프레임워크는 인증과 인가 과정을 단순화해 최종 사용자와 애플리케이션 설계자 모두의 경험을 개선합니다.

SSO FAQ

SSO는 무엇의 약자인가요?

SSO는 '싱글 사인온'의 약자입니다.

SSO 계정이란 무엇인가요?

SSO 계정은 하나의 로그인 자격 증명으로 여러 애플리케이션과 시스템에 액세스할 수 있는 중앙화된 인증 서비스입니다. 즉, 한 쌍의 사용자명과 비밀번호만 기억하면 조직이 제공하는 모든 서비스와 리소스에 액세스할 수 있습니다. SSO 계정은 로그인 과정을 간소화하고, 보안을 강화하고, 사용자가 업무에 필요한 정보와 도구에 더 쉽게 접근하도록 지원합니다.

SSO의 예시로는 어떤 것들이 있나요?

소비자 환경에서는 Amazon, Google, Meta, Microsoft 같은 대형 공급업체가 타사 애플리케이션을 위한 사용자 자격 증명을 제공할 수 있습니다. 자격 증명을 직접 입력하거나, 앞서 나열된 기업들의 계정 중 하나로 로그인하라는 대화상자를 본 적이 있다면 이미 SSO를 사용해 본 경험이 있는 것입니다.