엔터프라이즈 인증 방법 정보
GitHub.com에서 개인 계정을 사용하여 엔터프라이즈의 리소스에 액세스하고 필요에 따라 추가 SAML 액세스 제한을 구성하도록 허용하거나, Enterprise Managed Users을(를) 통해 ID 공급자(IdP)를 사용하여 엔터프라이즈에 대한 계정을 프로비저닝하고 제어할 수 있습니다. 자세한 내용은 "ID 및 액세스 관리 정보"을(를) 참조하세요.
SAML SSO 및 Enterprise Managed Users 모두 엔터프라이즈 리소스에 대한 보안을 강화합니다. Enterprise Managed Users는 엔터프라이즈 구성원에 대한 사용자 계정을 제어하고 계정이 수행할 수 있는 작업을 제한할 수 있습니다. 그러나 이러한 제한은 개발자의 워크플로를 방해하는 경우 엔터프라이즈에서 허용되지 않을 수 있습니다.
엔터프라이즈가 SAML SSO 또는 Enterprise Managed Users를 통해 더 많은 이점을 얻을 수 있는지 확인하려면 다음 질문을 스스로에게 해보세요.
사용자의 사용자 계정을 제어하려고 하나요?
Enterprise Managed Users는 엔터프라이즈 멤버가 GitHub.com에서 자신의 개인 계정을 사용하여 엔터프라이즈 리소스에 액세스하지 않도록 하려는 경우에 적합할 수 있습니다.
SAML SSO를 사용하면 개발자는 고유한 개인 계정을 만들고 관리하며 각 계정은 IdP의 SAML ID에 연결됩니다. Enterprise Managed Users는 사용자에 대한 계정을 프로비저닝하므로 다른 친숙한 SSO 솔루션과 비슷합니다. 사용자 이름 및 계정과 연결된 메일 주소를 제어하여 사용자 계정이 회사 ID를 준수하는지 확인할 수도 있습니다.
현재 사용자가 엔터프라이즈에서만 사용하도록 GitHub.com에 새 계정을 만들도록 요구하는 경우 Enterprise Managed Users가 적합할 수 있습니다. 그러나 IdP를 사용자 및 액세스 관리의 단일 데이터 소스(source of truth)로 사용하는 경우 SAML SSO가 더 나은 옵션이 될 수 있습니다. 예를 들어 엔터프라이즈에는 IdP에서 새 사용자를 온보딩하기 위한 정립된 프로세스가 없을 수 있습니다.
엔터프라이즈에서 사용하는 ID 공급자는 무엇인가요?
SAML SSO의 경우 SAML 2.0 표준을 준수하는 IdP를 사용하여 인증을 구성할 수 있습니다. GitHub에서는 다음 IdP를 공식적으로 지원하고 내부에서 테스트를 마쳤습니다. 자세한 내용은 "엔터프라이즈에 대한 SAML Single Sign-On 구성"을(를) 참조하세요.
GitHub은(는) ID 관리 시스템의 일부 개발자와 협력하여 Enterprise Managed Users과(와) "편리한" 통합을 제공합니다. 파트너 IdP를 사용하는 경우 인증 및 프로비저닝을 제공하도록 IdP에서 하나의 애플리케이션을 구성할 수 있습니다. 파트너 IdP를 사용하지 않거나 인증에 파트너 IdP만 사용하는 경우 SAML 2.0 및 SCIM(System for Cross-domain Identity Management) 2.0 표준을 구현하는 IdP를 통합할 수 있습니다. 자세한 내용은 "Enterprise Managed Users 정보"을(를) 참조하세요.
개발자가 퍼블릭 리포지토리, gists 또는 GitHub Pages 사이트에서 작업하나요?
GitHub.com에서 엔터프라이즈 멤버가 실수로 회사 소유 콘텐츠를 대중에게 유출하지 못하도록 하려면 Enterprise Managed Users에서 사용자가 수행할 수 있는 작업을 강력하게 제한합니다. 예를 들어 관리되는 사용자 계정은(는) 퍼블릭 리포지토리, gists(표시 여부는 관계없음) 또는 엔터프라이즈 외부에 표시되는 GitHub Pages 사이트를 만들 수 없습니다. 전체 제한 목록은 "AUTOTITLE"을(를) 참조하세요.
이러한 제한 사항이 일부 엔터프라이즈에서는 허용되지 않습니다. Enterprise Managed Users가 적합한지 확인하려면 개발자와 함께 제한을 검토하고 제한 사항이 기존 워크플로에 방해가 되는지 확인합니다. 이러한 경우 SAML SSO가 엔터프라이즈에 더 적합한 선택이 될 수 있습니다.
개발자가 엔터프라이즈 외부의 공동 작업에 의존하나요?
관리되는 사용자 계정은(는) 엔터프라이즈 내의 리포지토리에만 기여할 수 있습니다. 개발자가 프라이빗 리포지토리를 포함하여 엔터프라이즈 내부 및 외부의 리포지토리 둘 다에 기여해야 하는 경우 Enterprise Managed Users는 엔터프라이즈에 적합하지 않을 수 있습니다. SAML SSO가 더 나은 솔루션이 될 수 있습니다.
일부 회사에서는 GitHub.com에 SAML SSO를 사용하여 기존 엔터프라이즈 내에서 리포지토리를 유지 관리하고 관리되는 사용자가 있는 엔터프라이즈을(를) 만듭니다. 단일 워크스테이션에서 두 엔터프라이즈가 소유한 리포지토리에 기여하는 개발자는 단일 브라우저 내에서 GitHub.com의 계정 간에 전환하거나 각 계정에 다른 브라우저를 사용해야 합니다. 또한 개발자는 두 계정을 수용하기 위해 워크스테이션의 Git 구성을 사용자 지정해야 할 수도 있습니다. 이 워크플로의 복잡성으로 인해 내부 코드를 실수로 유출할 위험이 증가할 수 있습니다.
관리되는 사용자가 있는 엔터프라이즈을(를) 만들기로 결정했지만 개발자가 단일 워크스테이션에서 엔터프라이즈 외부의 리소스에 기여하도록 요구하는 경우 개발자의 로컬 Git 구성에서 계정 간 전환을 지원할 수 있습니다. 자세한 내용은 "Enterprise Managed Users 정보"을(를) 참조하세요.
엔터프라이즈에서 마이그레이션 비용을 허용할 수 있나요?
엔터프라이즈가 GitHub.com을 처음 사용하는 경우 SAML SSO 및 Enterprise Managed Users는 똑같이 쉽게 채택할 수 있습니다.
개발자가 자체 사용자 계정을 관리하는 데 GitHub.com을 이미 사용하고 있는 경우 Enterprise Managed Users를 채택하려면 새 엔터프라이즈 계정으로 마이그레이션해야 합니다. 자세한 내용은 "Enterprise Managed Users 정보"을(를) 참조하세요.
Enterprise Managed Users는 무료이지만 마이그레이션 프로세스에는 팀의 시간 또는 비용이 필요할 수 있습니다. 이 마이그레이션 프로세스가 비즈니스 및 개발자에게 허용되는지 확인합니다. 그렇지 않은 경우 SAML SSO가 더 나은 선택일 수 있습니다.