엔터프라이즈 유형 정보
GitHub Enterprise Cloud을(를) 사용하기 전에 엔터프라이즈 구성원이 조직, 리포지토리, 문제 및 끌어오기 요청과 같은 회사의 데이터에 액세스하는 방법을 결정해야 합니다.
GitHub Enterprise Cloud에서 엔터프라이즈 계정은 사용자가 공동 작업할 수 있는 중심 위치입니다. 엔터프라이즈 계정은 회사 데이터에 대한 액세스를 보호, 관리 및 제어하는 위치이기도 합니다. 자세한 내용은 "엔터프라이즈 계정 정보"을(를) 참조하세요.
사용자가 사용할 수 있는 기능은 사용자가 만드는 엔터프라이즈 유형에 따라 달라집니다. 다음 두 가지 엔터프라이즈 유형 중 하나를 선택할 수 있습니다.
| 엔터프라이즈 유형 | 사용자 ID | 인증 | 프로비저닝 |
|---|---|---|---|
| GitHub.com에 개인 계정이 있는 엔터프라이즈 | GitHub.com의기존 개인 계정 |
|
|
| 관리형 사용자가 있는 엔터프라이즈 | 외부 ID 관리 시스템에서 관리 |
|
|
회사가 GitHub Enterprise Cloud을(를) 처음 사용하는 경우 개인 계정 및 Enterprise Managed Users을(를) 보유한 엔터프라이즈도 똑같이 손쉽게 채택할 수 있습니다.
관리되는 환경에서 내부 원본을 연습하는 동안 오픈 소스 커뮤니티에서 현재 상태를 유지하기 위해 일부 회사는 GitHub.com에 개인 계정이 있는 기존 엔터프라이즈 내에서 리포지토리를 유지하고 별도의 관리형 사용자가 있는 엔터프라이즈을(를) 만듭니다.
귀사와 사용자에게 가장 적합한 엔터프라이즈 유형을 선택하려면 다음 질문을 자문해 봅니다.
사용자의 사용자 계정을 제어하려고 하나요?
Enterprise Managed Users는 엔터프라이즈 멤버가 GitHub.com에서 자신의 개인 계정을 사용하여 엔터프라이즈 리소스에 액세스하지 않도록 하려는 경우에 적합할 수 있습니다.
Enterprise Managed Users은(는) 사용자에게 진정한 SSO 환경을 제공합니다. Enterprise Managed Users을(를) 선택하는 경우 사용자의 계정을 프로비전하며 사용자는 별도의 사용자 계정에 로그인할 필요가 없습니다. 사용자 이름 및 계정과 연결된 메일 주소를 제어하여 이러한 사용자 계정이 회사 ID를 준수하는지 확인할 수도 있습니다.
Enterprise Managed Users을(를) 선택하지 않는 경우 각 사용자가 GitHub.com에서 개인 계정을 만들고 관리하고 로그인해야 합니다. 사용자가 개인 계정에 로그인하는 것 외에도 외부 ID 관리 시스템에 인증하도록 SAML 인증을 구성할 수 있습니다. SAML 인증에 성공하면 GitHub이(가) 사용자의 개인 계정을 ID 관리 시스템의 외부 ID에 연결합니다.
현재 사용자가 GitHub.com에 새 개인 계정을 만들어 회사의 리소스에 기여하도록 요구하는 경우 Enterprise Managed Users가 적합할 수 있습니다. 외부 ID 관리 시스템을 사용자 및 액세스 관리의 데이터 소스로 사용하는 경우 너무 복잡해지면 GitHub.com의 기존 개인 계정에 대한 추가 SAML 액세스 제어를 구성할 수 있는 엔터프라이즈를 만드는 것이 더 나은 옵션이 될 수 있습니다. 예를 들어 엔터프라이즈에는 ID 관리 시스템에 새 사용자를 온보딩하기 위한 정립된 프로세스가 없을 수 있습니다.
외부 ID 관리 시스템이 지원되나요?
GitHub.com에서 개인 계정을 사용하는 엔터프라이즈를 만들도록 선택한 경우, SAML 2.0 표준을 준수하는 외부 ID 관리 시스템으로 추가 인증을 구성할 수 있습니다. GitHub에서는 다음 ID 관리 시스템을 공식적으로 지원하고 내부에서 테스트를 마쳤습니다. 자세한 내용은 "엔터프라이즈에 대한 SAML Single Sign-On 구성"을(를) 참조하세요.
GitHub은(는) ID 관리 시스템의 일부 개발자와 협력하여 Enterprise Managed Users과(와) "편리한" 통합을 제공합니다. 구성을 간소화하고 완전한 지원을 보장하기 위해, GitHub에서는 인증 및 프로비전 모두에 단일 파트너 IdP를 사용할 것을 권장합니다. 파트너 IdP(ID 공급자)를 사용하는 경우 인증 및 프로비저닝을 제공하도록 IdP에서 하나의 애플리케이션을 구성할 수 있습니다. IdP는 SAML 2.0 표준을 지원해야 합니다. 또는 Entra ID(이전 Azure AD)를 사용하는 경우, OIDC(OpenID Connect) 인증을 구성할 수 있습니다. 파트너 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가 적합한지 확인하려면 사용자와 함께 제한을 검토하고 제한 사항이 기존 워크플로에 방해가 되는지 확인합니다. 그렇다면 개인 계정이 있는 엔터프라이즈가 더 적합한 선택이 될 수 있습니다.
사용자가 엔터프라이즈 외부의 공동 작업에 의존하나요?
관리형 사용자 계정은(는) 엔터프라이즈 내의 리포지토리에만 기여할 수 있습니다. 개발자가 프라이빗 리포지토리를 포함하여 엔터프라이즈 내부 및 외부의 리포지토리 모두에 기여해야 하는 경우 Enterprise Managed Users는 엔터프라이즈에 적합하지 않을 수 있습니다. 개인 계정이 있는 엔터프라이즈가 더 나은 솔루션이 될 수 있습니다.
회사에서 GitHub.com에 개인 계정이 있는 기존 엔터프라이즈 내에서 리포지토리를 유지 관리하고 별도의 관리형 사용자가 있는 엔터프라이즈도 만드는 경우 단일 워크스테이션에서 두 엔터프라이즈가 소유한 리포지토리에 기여하는 사용자는 브라우저 내에서 GitHub.com의 계정 간에 전환해야 합니다. 또한 사용자는 두 계정을 수용하기 위해 워크스테이션의 Git 구성을 사용자 지정해야 할 수도 있습니다. 이 워크플로의 복잡성으로 인해 내부 코드를 실수로 유출할 위험이 증가할 수 있습니다.
Enterprise Managed Users을(를) 선택했지만 사용자가 단일 워크스테이션에서 엔터프라이즈 외부의 리소스에 기여하도록 요구하는 경우 사용자의 로컬 Git 구성에서 계정 간 전환을 지원할 수 있습니다. 자세한 내용은 "Enterprise Managed Users 정보"을(를) 참조하세요.
엔터프라이즈에서 마이그레이션 비용을 허용할 수 있나요?
GitHub.com에서 개인 계정을 사용하는 엔터프라이즈가 이미 있는 경우 Enterprise Managed Users을(를) 채택하려면 새 엔터프라이즈 계정으로 마이그레이션해야 합니다. 자세한 내용은 "Enterprise Managed Users 정보"을(를) 참조하세요.
Enterprise Managed Users은(는) 개인 계정을 사용하는 엔터프라이즈와 비용의 차이가 없지만 마이그레이션 프로세스를 수행하는 데 팀의 시간 또는 비용이 소요될 수 있습니다. 이 마이그레이션 프로세스가 비즈니스 및 사용자에게 허용되는지 확인합니다. 그렇지 않은 경우 개인 계정이 있는 엔터프라이즈가 사용자에게 더 나은 선택이 될 수 있습니다.