싱글 사인온(SSO)이란 무엇인가요? SSO는 어떻게 작동합니까?

우리 모두 그렇게 하지 말아야 한다는 사실을 알고는 있지만, 결국 그렇게 합니다. 우리는 휴대폰 파일이나 지갑 속 종이에, 심지어는 키보드 뒷면에 붙어 있는 포스트잇 메모에 사용자명과 비밀번호를 적어 둡니다. 로그인 정보에 반려견의 이름과 숫자 몇 개, 구두점을 함께 사용하는 습관도 있습니다.

사실, 웹 세상을 살아가는 현대인들은 수십 개의 계정명과 비밀번호를 관리해야 합니다. 뛰어난 기억력을 타고난 사람이 아니라면 그 모두에 다른 정보를 사용하지는 않을 것입니다. 개중 대부분은 단순하고, 오래되었고, 누군가 정말 노력한다면 추측할 수 있는 내용일 것입니다. 이는 사이버 범죄자들에게 주는 선물과도 같습니다. 그렇게 취약한 정보를 사용하는 것은 100% 방지 가능한 일입니다.

싱글 사인온(SSO)이란 무엇인가요?

싱글 사인온(single sign-on) 기술은 직장과 개인 생활에서 우리를 괴롭히는 암호 문제에 대한 해결책 중 하나입니다. 해당 기술을 통해 인증 서버에 한 번만 로그인하면 참여 앱의 인증 자격 증명 역할을 하는 인증서를 대신 발급해 줍니다.

대부분의 독자께서는 이미 그런 시스템을 사용했을 가능성이 높습니다. 웹 애플리케이션에 대한 새 비밀번호를 생성하는 대신 "Apple로 로그인" 또는 Google 또는 다른 대형 공급업체의 ID 관리 시스템을 선택한 경우 SSO를 사용한 것입니다. 기업에서도 다른 인증 기술과 결합하여 기업 시스템을 보호하고 수십에서 수백 개의 애플리케이션 및 서비스에서 비밀번호 유지 관리가 가능하도록 하기 위해 SSO를 사용하는 경우가 점점 더 많아지고 있습니다.

주요 요점

• SSO는 많은 비밀번호와 사용자 이름 조합을 기억하는 개인의 부담을 덜어줍니다.
• SSO는 기업 전체를 하나의 인증 시스템으로 관리할 수 있어 IT 팀의 업무가 간편해집니다.
• 또한 SSO를 사용하면 응용 프로그램이 네트워크 연결을 관리하거나 소프트웨어 업데이트를 확인하는 서비스와 같이 응용 프로그램이 작동하는 데 필요한 서비스에 대해 사용자를 인증할 수 있습니다.

SSO 알아보기

싱글 사인온의 개념은 간단합니다. 즉, 유저 이름과 암호를 제공하거나 사용하는 각 응용 프로그램별로 사용자를 식별하는 대신 해당 정보를 인증 서버에 한 번만 제공합니다. 이 작업이 완료되면 인증 서버는 사용자가 SSO 시스템에 참여하는 응용 프로그램에 액세스할 때 사용자를 대신하여 식별 인증서를 전송합니다.

SSO는 기억해야 할 사용자명 및 암호 수를 줄여 줍니다. 또한 식별 자격 증명을 제공하는 횟수를 크게 줄여 광범위한 응용 프로그램을 더 쉽게 사용할 수 있으며 더 강력한 암호를 만들 수 있습니다. 엔터프라이즈 IT 기획자의 관점에서 볼 때, SSO를 사용하면 보안 절차를 업데이트하고 인증 서버에서 사용할 고급 인증 메커니즘을 배포할 수 있으므로 모든 응용 프로그램을 수정할 필요 없이 보다 안전한 인증을 사용할 수 있습니다.

개인 생활에서 각 앱에서 새 사용자 아이디와 비밀번호를 수동으로 설정하는 대신 주요 공급업체의 인증 시스템을 사용하면 몇 가지 이점이 있습니다. 한 가지 주요 장점은 연합 ID 관리 서비스를 제공하는 대형 공급업체는 고객이 맡긴 비밀번호 및 기타 개인 데이터를 잘 보호한다는 점입니다. 새로운 애플리케이션을 제공하는 새로운 공급업체는 고객이 제공한 자격 증명을 잘 보호하지 못할 수도 있습니다.

SSO는 어떻게 작동합니까?

SSO는 개별 응용 프로그램이 아닌 SSO 서버에 대해 자신을 인증하도록 사용자에게 요청하는 방식으로 작동합니다. 인증 프로세스가 완료되면 SSO 서버는 인증된 개인이 액세스하려는 응용 프로그램에 인증서를 제공합니다. 인증서는 사용자의 ID를 확인하는 역할을 합니다.

인증서는 일반적으로 특정 기간 동안만 유효하며 일반적으로 개별 사용자가 자신을 인증한 시스템에 연결됩니다. 참여하려면 SSO 서비스를 사용할 수 있도록 응용 프로그램을 작성해야 합니다. 기업에서 IT 기획자는 일반적으로 하나의 SSO 모델을 선택한 다음 애플리케이션이 이를 사용하여 직원의 ID를 확인하도록 요구합니다. 이는 고유의 사용자 인증서 저장소를 생성하거나 공통 SSO 구조를 지원하지 않을 수 있는 오래된 모놀리식 응용 프로그램에 문제가 될 수 있습니다.

공통 SSO 구성 유형

공통 SSO 구성 요소 및 개념은 중앙 집중식 ID 관리, 표준화 및 강력한 보안 조치를 포함한 여러 특성을 공유합니다. 한 가지 핵심은 상호 운용성입니다. 이러한 시스템은 사용자 친화적인 인증 프로세스를 보장하고 여러 애플리케이션에서 원활하게 작동할 수 있도록 함께 작동해야 합니다. 이를 달성하면 IT 팀은 최소한의 푸시백으로 더 안전한 비밀번호와 이중 인증을 요구할 수 있습니다.

• SAML. Security Assertion Markup Language는 애플리케이션에 대해 사용자를 인증하는 데 사용할 문서의 구조를 설명하는 기술 사양입니다. SAML은 널리 인정되는 XML 표준을 사용하여 ID 서버(ID 제공자라고도 함)가 생성하고 응용 프로그램으로 보내는 문서의 구조를 지정합니다. 이러한 응용 프로그램은 SSO 구문 분석에서 "서비스 제공자"라고도 합니다. SAML을 사용하는 모든 ID 제공자는 SAML을 인식하는 모든 애플리케이션에서 사용할 수 있는 인증서를 생성하므로 인터넷 애플리케이션에 적합합니다.

  SAML은 응용 프로그램이 수신하는 인증 정보가 변경되지 않도록 보장하는 방식을 제공하지 않습니다. 그것은 다른 기술에 의해 처리됩니다.

• Kerberos. Project Athena의 일환으로 1980년대 후반에 MIT에서 제작된 Kerberos는 완전한 인증 및 권한 부여 아키텍처입니다. Project Athena는 캠퍼스 전체에서 MIT 학생들이 보편적으로 접근할 수있는 컴퓨터 리소스 네트워크를 구축하고자했습니다. Kerberos는 원래 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을 사용하도록 구성할 수 있습니다. 보안성이 떨어지는 엔터프라이즈 네트워크용 NTLM 인증 시스템 대신 Kerberos를 기본값으로 사용하는 방법은 Microsoft를 비롯해 여러 기업에서 여전히 널리 사용되고 있습니다.

• OAuth. 인증 프레임워크를 포함하지 않는 개방형 권한 부여 프레임워크인 OAuth는 인터넷 응용 프로그램이 사용자를 대신하여 보호된 서비스의 리소스에 액세스해야 하는 경우의 기본 시스템입니다. Oracle과 Oracle Cloud Infrastructure(OCI)를 함께 사용하는 대부분의 클라우드 제공업체는 OAuth를 사용하여 클라우드 리소스에 대한 액세스를 관리합니다. 또한 Oracle은 개발자가 OAuth를 사용하는 자체 애플리케이션을 쉽게 생성할 수 있는 라이브러리 및 서비스를 제공합니다.

  다음은 OAuth 시스템의 핵심 구성 요소입니다.

  • 클라이언트 시스템은 일반적으로 인터넷에서 사용 가능한 다양한 서비스의 리소스에 액세스하고자 하는 최종 사용자 응용 프로그램입니다.
  • 권한 부여 서버는 클라이언트가 보호된 서비스에 액세스할 수 있도록 허용하는 토큰 요청을 수신합니다. 권한 부여 서버는 클라이언트의 인증서와 함께 토큰 요청을 수신합니다. 리소스 소유자가 승인한 액세스 토큰을 발행합니다.
  • 리소스 서버는 클라이언트가 사용하고자 하는 정보 또는 서비스를 제공합니다. 클라이언트로부터 유효한 액세스 토큰을 수신하면 데이터 또는 서비스를 제공합니다.

  액세스 토큰에 따라 다양한 액세스 권한 부여 유형을 지정할 수 있습니다. 필요한 신뢰 수준 및 클라이언트 장치의 특성에 따라 다양한 유형이 발행됩니다. 예를 들어, 스마트 TV는 랩탑과 다른 액세스 권한을 부여받을 수 있습니다.

• OpenID Connect(OIDC). OpenID Connect는 OAuth와 함께 사용하도록 구축된 ID 관리 시스템입니다. OIDC와 OAuth는 웹 기반 애플리케이션 및 모바일 애플리케이션과 같은 인터넷 네이티브 시스템을 위한 완전한 SSO 환경을 제공합니다. 인증서 정보 반환의 기준으로 SAML을 사용하는 대신 OIDC는 아래에 설명된 JSON 웹 토큰 및 RESTful 프로토콜로 알려진 JSON 문서를 사용합니다. 둘 다 인터넷의 기본이며 개발자가 사용하기 쉽습니다.

  OIDC는 Kerberos와 같은 대칭 키 암호화를 사용하는 대신 공용 키 암호화를 사용하므로 인터넷과 같은 도메인 없는 네트워크에 더 적합합니다.

• 스마트 카드 인증. OIDC와 같은 시스템은 공개 키 암호화를 사용하여 인증 중 및 인증 후에 의도한 수신자만 ID 관리 제공자와 교환된 데이터를 볼 수 있도록 합니다. 퍼블릭 키 암호화는 비대칭적이며, 클라이언트 또는 서버로 전송할 메시지를 암호화하는 데 사용할 수 있는 퍼블릭 키와, 메시지를 해독하는 데 사용해야 하는 비밀 프라이빗 키로 구성됩니다.

  일반적으로 개인 키는 사용자의 장치에 저장됩니다. 대부분의 노트북에는 TPM(Trusted Platform Module) 기술을 사용하여 시스템용 메시지를 해독하는 변조 방지 칩이 포함되어 있습니다. 애플과 안드로이드 폰은 다르지만 비슷한 시스템을 사용합니다. Apple 시스템의 이름은 Secure Enclave이고 Android의 이름은 Android Knox입니다. 이러한 기술을 통해 장치는 적절하게 요청하는 모든 시스템에 공개 키를 제공하고 수신하는 메시지를 해독하기 위해 분할되지 않은 개인 키를 사용할 수 있습니다.

  이러한 시스템의 장점은 기기의 사용자가 시스템에서 암호화가 어떻게 처리되는지 알 필요가 없다는 점입니다. 단점은 사용자가 소유하는 각 장치가 고유한 공개/개인 키 쌍을 가지므로 장치가 암호화 프로세스에서 개별적으로 알려져 있다는 것입니다. 랩톱이나 전화가 분실되거나 도난당한 경우 도둑이 소유자의 암호를 알고 있으면 암호화 시스템이 액세스를 방지하는 데 도움이 되지 않습니다.

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

• 엔터프라이즈 SSO. 복잡한 애플리케이션 인프라를 보유한 대기업은 네트워크 범위로 제한되는 엔터프라이즈 SSO 또는 eSSO 시스템을 생성할 수 있습니다. 직원들은 업무에 필요한 앱을 얻기 위해 하나 또는 두 개의 비밀번호와 사용자 이름만 알아야 하며, 조직은 시스템 및 데이터에 대해 더 효과적이고 관리하기 쉬운 보안의 이점을 누릴 수 있습니다. 이러한 eSSO 시스템은 키를 보다 쉽게 취소할 수 있는 기능을 기반으로 대칭 키 암호화를 선호할 수 있고 잘 알려진 형식으로 SAML을 선호할 수 있으며 종종 엔드포인트 보안 향상을 위해 다양한 종류의 다중 요소 인증을 사용합니다.

  SaaS 애플리케이션이 더 일반화됨에 따라 기업은 인터넷에서 더 일반적으로 사용되는 OAuth과 같은 시스템으로 이동하거나 SaaS 애플리케이션이 회사가 선택한 eSSO 프레임워크에 적합하도록 요구할 수 있습니다. SAML은 엔터프라이즈 네트워크 및 인터넷을 통해 사용할 수 있습니다. 많은 SaaS 응용 프로그램은 사용자 인증을 위해 두 프레임워크를 모두 지원합니다.

• 웹 SSO. 웹 애플리케이션은 사용자 활동을 승인하는 데는 OAuth를 사용하고 사용자를 인증하는 데는 OpenID Connect를 사용하는 것이 더 효과적일 수도 있고, 그것만을 사용해야 할 수도 있습니다. 인터넷을 전송 수단으로 가정하기 때문에 웹 SSO 시스템의 구성 요소는 IETF 표준으로 정의되어 있으므로 웹 개발자가 예상하고 이해할 수 있는 방식으로 작동하는 경향이 있습니다. 또한 인증은 권한 부여와 긴밀하게 결합되어 있으며 JSON 기반 REST 프로토콜 및 정보 표준과 같은 액세스 방법을 사용하여 완전하고 확장 가능한 시스템을 만듭니다. 웹 SSO 시스템은 도메인 전반에서 대규모로 작동하도록 설계되었습니다.

• LDAP. Lightweight Directory Access Protocol은 사용자가 서버나 프린터와 같은 로컬 네트워크에서 사용할 수 있는 리소스를 찾을 수 있도록 1990년대에 처음 도입되었습니다. 도메인 내의 모든 리소스를 파악할 수 있는 권한 있는 서버를 구상합니다. 따라서, LDAP은 인터넷 사용에 적합하지 않습니다.

  LDAP은 네트워크 리소스에 대한 액세스 권한을 부여하는 데 사용되므로 LDAP 서버에 저장된 사용자 자격 증명이 있는 사용자 인증 시스템이 포함됩니다. 사용자 인증 방식은 강력하지 않습니다. 예를 들어, 네트워크를 통해 암호를 일반 텍스트로 보냅니다. 암호화는 SSL/TLS와 같은 다른 프로토콜에서 제공할 수 있습니다.

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

• JWT. JSON 웹 토큰은 구조화된 방식으로 당사자 간에 정보를 안전하게 전송하는 데 사용되는 소형 문서입니다. 이들은 SAML 문서와 동일한 요구 사항을 채우지만 URL에 포함하기에 적합한 모호한 형식으로 채웁니다. JWT는 신뢰성을 보장하기 위해 공개 키 암호화 기술을 사용하여 암호화적으로 서명됩니다. Oath(Open Authentication)에서는 사용자가 인증되면 ID 서버가 JSON ID 토큰을 반환합니다.

  보호된 리소스에 액세스하기 위한 권한 부여 요청은 이후에 JSON 액세스 토큰을 반환하며, 이 토큰은 리소스 서버에 대한 모든 요청에 포함되어야 합니다. 이러한 트랜잭션은 각 요청의 일부로 클라이언트의 상태(이 경우 인증 및 권한 부여)를 전송하므로 소위 RESTful 교환이라고 합니다. "표현 상태 전송"을 의미하는 REST는 리소스 서버가 서버 리소스를 사용하려는 모든 클라이언트와의 세션을 설정 및 유지 관리할 필요가 없기 때문에 유용합니다.

  JWT는 일반 텍스트 문서이므로 HTTPS로 암호화된 연결을 통해 사용해야 합니다. 토큰은 일반적으로 개인 식별 정보와 같은 민감한 데이터를 포함하지 않도록 설계되었습니다. 각 토큰은 공개 키 인증서 형식을 위한 국제 표준인 X.509에 따라 서명되므로 리소스 서버에서 해당 서명의 유효성을 검사하여 토큰이 변조되지 않았는지 확인합니다. JWT는 OAuth/OpenID 인증 및 권한 부여 시스템의 구성요소입니다. 웹 애플리케이션에서 사용하도록 설계되었으며 확장성이 우수하며 도메인 전체에서 사용됩니다.

SSO의 이점

IT 및 보안 전문가들은 사용자 인증을 중앙 집중화하고, 잠재적으로 민감한 정보를 보호하며, 기업 시스템 및 애플리케이션과의 통합을 관리하는 것을 의미한다는 점을 잘 알고 있기 때문에 SSO를 선호하는 경향이 있습니다. 이들은 일반적으로 필요한 사용자 교육과 지속적인 모니터링 및 유지 관리 문제를 기꺼이 해결합니다. 이것은 SSO 기술과 함께 제공되는 몇 가지 중요한 이점의 직접적인 결과입니다.

• 중앙 집중식 액세스. SSO 시스템은 대부분의 기업 및 인터넷 클라우드 제공업체가 유지 관리하는 여러 애플리케이션에 대한 사용자 계정 관리 및 액세스 부담을 단순화합니다. 모든 응용 프로그램에 대한 사용자 액세스 권한을 한 곳에서 부여 및 취소할 수 있습니다. 따라서 예를 들어 직원이 조직을 떠나는 경우 관리자는 각 애플리케이션에 대한 직원의 자격 증명을 개별적으로 제거할 필요가 없습니다. 보안 전문가는 또한 각 응용 프로그램을 변경할 필요 없이 한 곳에서 인증 시스템을 변경할 수 있습니다.
• 보안성 향상. SSO는 직원이 메모리에 커밋해야 하는 사용자 이름과 암호 쌍의 수를 크게 줄입니다. 이러한 부담이 줄어들기 때문에 특히 기업에서는 다단계 인증 및 강력한 암호 정책을 통해 인증 교환의 보안을 개선하는 것이 합리적입니다.
• 직원 생산성 강화. 직원들은 SSO를 사용할 때 사용자 이름과 암호를 기억하는 데 어려움을 겪을 것입니다. 인증된 사용자는 보통 재인증 없이 애플리케이션에 액세스할 수 있습니다. 따라서 SSO를 사용하면 직원이 원하는 작업을 더 빠르게 수행할 수 있습니다. 구현 세부 정보에 따라 사용 중인 응용 프로그램에 인증해야 할 수도 있지만 최소한 SSO 자격 증명만 기억하면 됩니다.
• 비밀번호 피로도 감소. 누구도 수십 개의 사용자 이름과 암호 쌍을 다루고 싶어하지 않습니다. 복잡한 비밀번호를 기억하는 어려움(특히 자주 변경해야 할 경우)은 사용자의 불편함을 초래할 수 있으며, 이로 인해 사람들이 쉽게 추측할 수 있는 비밀번호를 사용하거나, 동일한 비밀번호를 여러 계정에 재사용하거나, 포스트잇 메모를 이용한 비밀번호 관리 방법을 사용하는 결과로 이어질 수 있습니다. SSO는 그런 부담을 덜어줍니다.
• 규제 준수. SSO는 방금 설명한 중앙 집중식 액세스 관리의 이점을 통해 규제 준수를 용이하게 할 수 있습니다. 확인할 SSO 프레임워크가 하나뿐이므로 감사 및 수정도 간소화됩니다.
• 통합 간소화. 일반적인 기업은 여러 데이터베이스 인스턴스에 저장된 페타바이트급 데이터를 관리합니다. 제조 데이터를 위한 데이터베이스 하나, 공급망 데이터를 위한 데이터베이스 하나, 재무 데이터, 마케팅 데이터, 영업 데이터 등을 위한 데이터베이스 하나 등을 상상하는 것은 어렵지 않습니다. 또한 영업 담당자가 재고 데이터에 액세스하는 것이 얼마나 도움이 될지 쉽게 알 수 있습니다. CRM 시스템은 해당 데이터에 액세스할 수 있지만 각 영업 사원의 정보는 재고 관리 데이터베이스 및 CRM 시스템에 알려져 있어야 합니다. SSO는 요청자의 필요한 검증된 ID를 제공할 수 있으며, 액세스 토큰은 각 역할의 개인이 볼 수 있는 데이터를 결정하는 데 도움이 될 수 있습니다. SSO가 없으면 CRM과 재고 시스템 간의 통합이 생성 및 관리가 훨씬 어려워지며 사용자를 위한 또 다른 인증 단계나 재고 데이터에 대한 보안이 약해질 수 있습니다.
• 간소화된 사용자 경험. 엔터프라이즈 애플리케이션 및 웹 애플리케이션에 대한 인증의 필요성을 줄이면 일반적으로 사용자 경험이 향상됩니다. 또한 많은 사람들이 개인 온라인 계정을 통해 SSO에 익숙해져 있기 때문에 최소한의 교육만 받으면 되는 경우가 많습니다.

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

첫째, 완전한 보안이라는 것은 존재하지 않으며 보안의 정도만 달라질 뿐입니다. 즉, 상업적으로 이용할 수 있는 모든 SSO 프레임워크는 매우 안전하며, 이는 해당 기술의 핵심입니다. 일반적으로 SSO 시스템 자체는 완전한 보안 솔루션이 아닙니다. 대신 보안 환경의 중요한 구성 요소입니다. 사용자를 인증하고 응용 프로그램 및 기타 리소스 제공 시스템에 인증 자격 증명을 제공하는 시스템 역할은 전체 보안 전략의 중요한 부분입니다.

SSO 및 프라이버시

SSO는 자체적으로 더 나은 프라이버시를 제공하지만 각 구현마다 프라이버시가 다를 수 있습니다. 예를 들어, SAML 및 JWT 응답은 최소한도의 인증 검증을 포함합니다. 또한 사용자에게 적용되는 그룹 및 역할과 같은 정보뿐만 아니라 구현자가 제공하기로 선택한 다른 데이터도 포함할 수 있습니다.

웹 기반 리테일 또는 소셜 미디어에서 응용 프로그램이 사용자의 연령, 위치 및 기타 개인 정보를 알면 유용할 수 있습니다. 일반적으로 이러한 개인정보를 Facebook에 제공하는 경우, 개인정보 처리방침에서 제공하지 않는다고 명시하거나 앱에서 명시적으로 일부 정보를 공유하지 않는다고 허용하지 않는 한 Facebook이 해당 정보를 다른 사람에게 제공한다고 가정합니다.

기업에서 SSO 시스템은 사용자가 조직에 가지고 있는 관련 역할과 함께 인증 검증을 반환해야 합니다. 또한 사용자가 근무하는 회사 사무실과 회사 전화 번호를 제공하는 것이 유용할 수 있습니다. 다른 정보는 더 얻기 어려워야 합니다. 기본적으로 제공되는 내용은 일반적으로 HR 정책에 따라 결정됩니다.

SSO 사용 사례

SSO는 사용자에게 하나의 로그인 자격 증명 세트만으로 여러 응용 프로그램 및 시스템에 대한 원활한 액세스를 제공하도록 설계되었습니다. 엄격한 규제 준수 요구 사항이 있는 조직은 추가적인 보안 조치를 구현해야 할 수도 있지만 SSO에 대한 사용 사례는 많습니다. 여기에는 다음이 포함됩니다.

• 엔터프라이즈 애플리케이션. 일반적으로 기업은 수십에서 수백 개의 애플리케이션을 관리하며, 각 애플리케이션에는 사용자를 인증해야 합니다. 응용 프로그램별로 ID 관리 시스템을 생성하고 유지 관리하는 것은 사용자나 IT 팀에게는 실용적이지 않습니다. SSO는 직원을 한 번 인증한 다음 해당 일회성 인증을 기반으로 리소스를 사용하도록 권한 부여를 관리할 수 있는 방법을 제공합니다.

  인증 검증은 일반적으로 특정 기간 및 단일 시스템에 대해서만 유효합니다. 회사 내 각 직원의 역할에 대한 보다 세부적인 세부 정보는 SSO 시스템에 의해 유지되고 애플리케이션, 데이터 및 기타 리소스에 대한 제한된 액세스를 제공하기 위해 애플리케이션 또는 권한 부여 시스템에서 사용될 수 있습니다.

• 클라우드 기반 애플리케이션. 비즈니스 및 소비자용 클라우드 기반 시스템은 기업용 SSO 시스템과는 다른 식별 및 승인 요구 사항을 제공합니다. 소비자의 편의상 사용자가 인증되면 해당 장치에서 영구적으로 서비스를 사용할 수 있습니다. 예를 들어, Gmail에 로그인하면 재인증 없이 Docs, Sheets 같은 다른 Google 애플리케이션을 사용할 수 있습니다. 비즈니스에서 SaaS 애플리케이션 또는 플랫폼과 서비스형 인프라를 제공하는 클라우드 서비스 제공업체는 사용자 ID가 확인되면 서비스에 대한 광범위한 액세스를 허용합니다. 인증은 사용자가 한 번 로그인하여 광범위한 서비스를 사용할 수 있도록 하는 더 큰 서비스 권한 부여 체계의 첫번째 단계입니다. 서비스 액세스 권한은 각 애플리케이션에 대한 각 사용자의 역할(예: 한 애플리케이션은 관리자, 다른 애플리케이션은 개발자, 다른 애플리케이션은 최종 사용자 등)에 따라 달라집니다. 접근 권한은 조직이 지불한 금액에 따라 달라집니다.

SSO 구현

사내 보안 전문 지식이 부족하다고 해서 SSO 도입을 망설이지 마세요. 관리형 보안 서비스 제공업체와 SSO 공급업체 구현 팀이 함께 지원합니다. 많은 기업들이 타사 제공업체가 제공하는 SSO 서비스를 사용하고 있습니다. 기업은 전문성, 고급 보안 기능 및 확장성의 이점을 누릴 수 있으며, IT 팀은 SSO 관리를 전문가에게 맡기고 비즈니스 성장을 지원하는 데 집중할 수 있습니다.

높은 수준의 구현에는 세 가지 주요 요소가 필요합니다.

1. 사용자 이름 및 비밀번호와 같은 최종 사용자 입력을 안전하게 수집할 클라이언트 인증 시스템을 선택 및 배포합니다. 기업에서도 이러한 시스템은 종종 웹 페이지로 제공되므로 여러 장치에서 인증 프로세스를 균일하게 유지하기 쉽습니다. 일반적으로 기업에서 사용자는 회사의 네트워크에 있거나 VPN을 통해 액세스해야 합니다. 이 요구 사항을 통해 조직은 신뢰할 수 있는 단일 ID 관리 시스템을 만들 수 있습니다.
2. 사용자를 인증하고 조직 대신 인증서를 발행할 ID 관리자를 설정합니다. 대부분의 스토어에서 ID 관리자는 앱 내에서 개인이 수행할 수 있는 작업을 애플리케이션에 알려주는 사용자 인증 토큰을 제공하는 시스템의 일부이거나 인증 서버와 긴밀하게 연결되어 있습니다.
3. 자체 사용자 ID 시스템을 유지하는 대신 SSO 및 권한 부여 시스템의 인증서와 토큰을 사용하도록 애플리케이션 구성 또는 수정합니다.

SSO 모범 사례

사내에서 구현하든, 제3자의 도움을 받아 구현하든, 서비스형 모델을 사용하든 성공의 열쇠가 존재합니다. 여기에는 다음이 포함됩니다.

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는 Single Sign-On을 의미합니다.

내 SSO 계정이란 무엇입니까?

SSO 계정은 하나의 로그인 자격 증명 세트를 사용하여 여러 응용 프로그램 및 시스템에 액세스할 수 있는 중앙 집중식 인증 서비스입니다. 즉, 조직에서 제공하는 모든 서비스와 리소스에 액세스하려면 사용자 이름과 암호 하나만 기억하면 됩니다. SSO 계정은 로그인 프로세스를 간소화하고 보안을 향상시키며 사용자가 자신의 작업을 수행하는 데 필요한 정보와 도구에 쉽게 액세스할 수 있도록 합니다.

SSO의 예시는 무엇인가요?

소비자 공간에서는 Amazon, Google, Meta 및 Microsoft와 같은 대규모 공급업체가 다른 애플리케이션에 대한 사용자 자격 증명의 소스 역할을 할 수 있습니다. 위 서비스 중 하나를 사용하여 자격 증명을 입력하거나 로그인할 수 있는 대화 상자가 표시된 경우 SSO를 사용한 것입니다.