GitHub App을(를) 대신 사용
가능하면 OAuth app 대신 GitHub App을(를) 사용하는 것이 좋습니다. 일반적으로 GitHub Apps은(는) OAuth apps보다 선호됩니다. GitHub Apps은(는) 세분화된 사용 권한으로 사용자가 앱이 액세스할 수 있는 리포지토리를 더 잘 제어할 수 있으며 수명이 짧은 토큰을 사용합니다. 이러한 속성은 앱의 자격 증명이 유출될 경우에 발생 가능한 손상을 제한하여 앱의 보안을 강화할 수 있습니다.
OAuth apps와(과) 마찬가지로 GitHub Apps은(는) 여전히 OAuth 2.0을 사용하고 OAuth 토큰 유형(사용자 액세스 토큰)을 생성하여 사용자 대신 작업을 수행할 수 있습니다. 그러나 GitHub Apps은(는) 사용자와 독립적으로 작동할 수도 있습니다.
GitHub Apps에 대한 자세한 내용은 "GitHub 앱 만들기 정보"을(를) 참조하세요.
기존 OAuth app을(를) GitHub App(으)로 마이그레이션하는 방법에 대한 자세한 내용은 "OAuth 앱을 GitHub 앱으로 마이그레이션"을(를) 참조하세요.
최소 범위 사용
OAuth app은(는) 앱이 의도한 기능을 수행하는 데 필요한 범위만 요청해야 합니다. 앱의 토큰이 손상되면 발생할 수 있는 손상의 양이 제한됩니다. 자세한 내용은 "OAuth 앱 권한 부여"을(를) 참조하세요.
앱의 자격 증명 보호
클라이언트 암호를 사용하면 앱에서 사용자에게 권한을 부여하고 사용자 액세스 토큰을 생성할 수 있습니다. 이러한 토큰은 사용자를 대신하여 API 요청을 만드는 데 사용할 수 있습니다.
앱의 클라이언트 암호와 생성된 모든 토큰을 안전하게 저장해야 합니다. 스토리지 메커니즘은 통합 아키텍처 및 실행되는 플랫폼에 따라 달라집니다. 일반적으로 사용 중인 플랫폼에 중요한 데이터를 저장하기 위한 스토리지 메커니즘을 사용해야 합니다.
클라이언트 암호
앱이 웹 사이트 또는 웹앱인 경우 클라이언트 암호를 Azure Key Vault와 같은 키 자격 증명 모음에 저장하거나 서버의 암호화된 환경 변수 또는 암호로 저장하는 것이 좋습니다.
앱이 네이티브 클라이언트, 클라이언트 쪽 앱이거나 사용자 디바이스에서 실행되는 경우(서버에서 실행되지 않음) 클라이언트 암호를 보호할 수 없습니다. 앱에서 생성된 토큰을 기반으로 고유의 서비스에 대한 액세스를 제어하려는 경우 누구나 클라이언트 암호에 액세스하여 토큰을 생성할 수 있으므로 주의해야 합니다.
사용자 액세스 토큰
앱이 웹 사이트 또는 웹앱인 경우 백 엔드에서 토큰을 암호화하고 토큰에 액세스할 수 있는 시스템과 관련된 보안이 있는지 확인해야 합니다. 활성 액세스 토큰과 별도의 위치에 새로 고침 토큰을 저장하는 것이 좋습니다.
앱이 네이티브 클라이언트, 클라이언트 쪽 앱 또는 사용자 디바이스에서 실행되는 경우(서버에서 실행되지 않음) 서버에서 실행되는 앱뿐만 아니라 토큰도 보호하지 못할 수 있습니다. 앱 플랫폼에 권장되는 메커니즘을 통해 토큰을 저장하고 스토리지 메커니즘의 보안이 완전하지 않을 수 있다는 점에 유의해야 합니다.
적절한 토큰 형식 사용하기
OAuth apps은(는) 인증된 API 요청을 만들기 위해 사용자 액세스 토큰을 생성할 수 있습니다. 앱은 인증을 위해 personal access token 또는 GitHub 암호를 사용하면 안 됩니다.
보안 위반 처리를 위한 계획 수립
보안 위반을 적시에 처리할 수 있도록 계획이 있어야 합니다.
앱의 클라이언트 암호가 손상된 경우 새 암호를 생성하고, 새 암호를 사용하도록 앱을 업데이트하고, 이전 암호를 삭제해야 합니다.
사용자 액세스 토큰이 손상된 경우 해당 토큰을 즉시 철회해야 합니다. 자세한 내용은 "OAuth 권한 부여에 대한 REST API 엔드포인트"을(를) 참조하세요.
사용자의 조직 액세스 권한 확인
OAuth 앱은 조직 또는 엔터프라이즈 외부의 사용자가 액세스할 수 있습니다. 조직 또는 엔터프라이즈의 구성원만 앱을 사용하길 원하는 경우 사용자가 앱에 로그인할 때 사용자의 멤버 자격 상태를 검사해야 합니다.
사용자가 구성원인 조직 목록을 찾으려면 "인증된 사용자에 대한 조직 나열" 엔드포인트를 사용할 수 있습니다. 그런 다음 앱에서 승인된 조직 목록과 대조하여 이 목록의 유효성을 검사할 수 있습니다. 자세한 내용은 "조직에 대한 REST API 엔드포인트"을(를) 참조하세요.
참고: 관리형 사용자 계정 또는 관리형 사용자가 있는 조직에서 만든 OAuth app도 엔터프라이즈 외부의 사용자가 액세스할 수 있습니다.
정기적인 취약성 검사 수행
앱에 대한 정기적인 약점 검사를 수행해야 합니다. 예를 들어 앱의 코드를 호스트하는 리포지토리에 대한 코드 검사 및 비밀 검사를 설정할 수 있습니다. 자세한 내용은 "코드 검사 정보" 및 비밀 검사 정보을 참조하세요.
적절한 환경 선택하기
앱이 서버에서 실행되는 경우 서버 환경이 안전한지, 앱에 대해 예상되는 트래픽 볼륨을 처리할 수 있는지 확인합니다.
안전한 방식으로 서비스 사용하기
앱에서 제3자 서비스를 사용하는 경우 안전한 방식으로 사용해야 합니다.
- 앱에서 사용되는 모든 서비스에는 고유한 로그인 및 암호가 있어야 합니다.
- 앱은 SaaS 서비스를 관리하기 위해 이메일 또는 데이터베이스 서비스와 같은 서비스 계정을 공유해서는 안 됩니다.
- 관리 업무를 수행하는 직원만 앱을 호스트하는 인프라에 대한 관리자 액세스 권한을 가져야 합니다.
로깅 및 모니터링 추가
앱에 대한 로깅 및 모니터링 기능을 추가하는 것이 좋습니다. 보안 로그에는 다음이 포함될 수 있습니다.
- 인증 및 권한 부여 이벤트
- 서비스 구성 변경 내용
- 데이터 읽기 및 쓰기
- 사용자 및 그룹 권한 변경
- 관리자로 역할 상승
로그는 각 이벤트에 대해 일관된 타임스탬프를 사용해야 하며 기록된 모든 이벤트에 대한 사용자, IP 주소, 호스트 이름을 기록해야 합니다.
데이터 삭제 활성화
다른 사용자가 앱을 사용할 수 있는 경우 사용자에게 데이터를 삭제할 방법을 제공해야 합니다. 사용자가 데이터를 삭제하기 위해 지원 담당자에게 이메일을 보내거나 전화를 걸 필요가 없어야 합니다.