리포지토리에서 유출된 비밀 수정

소개

API 키, 토큰, 자격 증명과 같은 비밀은 실수로 코드베이스에 노출되거나 부적절하게 저장된 경우 팀 및 조직에 상당한 보안 위험을 초래할 수 있습니다.

유출된 비밀은 즉시 손상된 것으로 간주해야 하며 비밀 철회와 같은 적절한 수정 단계를 수행해야 합니다. 단순히 코드베이스에서 비밀을 제거하거나, 새 커밋을 푸시하거나, 리포지토리를 삭제하고 다시 만드는 것만으로는 비밀이 악용되는 것을 방지할 수 없습니다.

이 방법에서는 실수로 리포지토리에 비밀을 커밋했거나 리포지토리에서 비밀 유출에 대한 경고를 받은 경우 해야 할 일을 안내합니다.

필수 조건

• 적어도 리포지토리에 대한 쓰기 권한이 있어야 합니다.
• 선택 사항: 리포지토리에 대해 Secret scanning을 사용하도록 설정합니다.

  참고 항목

  Secret scanning은 퍼블릭 리포지토리에 대해 무료입니다. 이는 GitHub Team 및 GitHub Enterprise Cloud 플랜의 프라이빗 리포지토리에 대한 GitHub Advanced Security의 일부로 사용할 수 있습니다.

1단계. 비밀 식별 및 컨텍스트 수집

유출된 비밀에 대해 최대한 많은 정보를 수집합니다. 이렇게 하면 위험을 평가하고 수정을 위한 최선의 작업을 결정하는 데 도움이 됩니다.

1. 비밀 형식 및 해당 공급자를 확인합니다.
   • 예를 들어 비밀이 GitHub personal access token(PAT), OpenAI API 키, SSH 프라이빗 키인가요?
2. 유출된 비밀을 포함하는 리포지토리, 파일, 줄을 찾습니다.
3. 비밀 소유자를 식별합니다. 이는 비밀을 만들거나 책임을 지는 사람 또는 팀입니다.
   • 리포지토리의 CODEOWNERS 파일을 확인하여 책임 있는 팀을 확인합니다.
   • git log -S를 사용하여 리포지토리의 커밋 기록을 검색하여 비밀을 커밋한 사람을 식별할 수 있습니다.

2단계. 위험 평가

수정에 접근하는 방법은 비밀 유출과 관련된 위험 요인에 따라 결정됩니다.

Secret scanning은 경고와 관련된 위험을 평가하는 데 도움이 될 수 있지만 아직 secret scanning을 사용하도록 설정하지 않은 경우에도 사용 가능한 정보에 따라 위험 평가를 수행할 수 있습니다.

옵션 1. Secret scanning을 사용하도록 설정한 경우

유출과 관련된 secret scanning 경고를 검토하고 경고 레이블 및 사용 가능한 메타데이터를 확인합니다.

1. 비밀의 유효성 상태를 확인하여 비밀이 여전히 활성 상태인지 확인합니다. 경고에는 상태가 포함되며, 이는 비밀이 활성 상태인지, 비활성 상태인지, 유효성을 알 수 없는지 여부를 설명합니다.

   참고 항목

   • 유효성 검사는 특정 비밀 유형에 대해서만 사용할 수 있습니다. 비밀 유형이 지원되는지 확인하려면 지원되는 비밀 검사 패턴을(를) 참조하세요.
   • 비밀 공급자는 항상 비밀의 유효성을 확인하기 위한 가장 신뢰할 수 있는 소스입니다.
2. public exposure 레이블을 확인하여 비밀이 퍼블릭 리포지토리에서 유출되었는지 확인합니다.
3. multiple leaks 레이블을 확인하여 비밀이 여러 위치에 노출되는지 확인합니다.
4. 비밀이 GitHub PAT인 경우 경고 메타데이터에서 비밀이 마지막으로 사용된 시기와 해당 액세스 범위에 대한 정보를 확인합니다.
5. 비밀에 종속된 서비스 또는 애플리케이션을 평가하고, 비밀을 즉시 철회하는 경우 가동 중지 시간 또는 중단 가능성을 고려합니다.

옵션 2. Secret scanning을 사용하도록 설정하지 않은 경우

리포지토리에 대해 아직 secret scanning을 사용하도록 설정하지 않은 경우 다음을 기반으로 위험 평가를 수행합니다.

1. 리포지토리의 표시 여부를 확인합니다. 리포지토리가 퍼블릭인가요?
2. 비밀이 최근에 사용되었다는 표시를 찾습니다. 비밀을 참조하는 최근 커밋 또는 끌어오기 요청이 있나요? 사용 중인 비밀을 보여 주는 로그 또는 감사 내역이 있나요?
3. 비밀 및 주변 컨텍스트가 포함된 파일을 평가합니다. 비밀이 프로덕션 배포 스크립트(높은 위험 수준) 또는 테스트 파일(낮은 위험 수준)에 사용되어 있나요? 비밀이 데이터베이스 자격 증명 또는 관리자 키(높은 위험 수준)와 연결되어 있나요?
4. 비밀에 종속된 서비스 또는 애플리케이션을 평가하고, 비밀을 즉시 철회하는 경우 가동 중지 시간 또는 중단 가능성을 고려합니다.

3단계 수정 전략화

다음 단계는 이전 단계에서 수행한 위험 평가에 따라 달라집니다.

위험 수준이 높은 비밀에 대한 신속한 조치

자동화된 스캐너는 몇 분 안에 공개적으로 노출된 비밀을 찾을 수 있습니다. 그러한 비밀은 몇 시간 내에 악의적인 행위자가 악용할 수 있습니다. 활성 비밀이 더 오래 노출될수록 심각한 침해 가능성이 커집니다.

비밀의 위험 수준이 높은 경우(즉, 비밀이 여전히 활성 상태이거나, 퍼블릭 리포지토리에 노출되거나, 프로덕션 자격 증명인 경우) 다음을 수행하는 것이 좋습니다.

1. 비밀을 즉시 철회하는 것을 우선시합니다. 4단계를 참조하세요.

   참고 항목

   서비스에 대한 가동 중지 시간이 우려되는 경우 먼저 동일한 권한으로 새 비밀을 생성하고, 애플리케이션이 새 토큰을 사용하기 시작하도록 한 다음, 이전 비밀을 철회할 수 있습니다.

2. 철회 중이나 이후에 비밀 소유자(1단계에서 식별), 리포지토리 관리자, 보안 담당자와 커뮤니케이션합니다.

위험 수준이 중간이거나 낮은 비밀에 대한 계획

비밀이 중간에서 낮은 위험(즉, 비밀이 더 이상 활성 상태가 아니거나, 프라이빗 리포지토리에 노출되거나, 테스트 또는 개발 자격 증명인 경우) 이에 따라 수정 전략을 계획할 수 있습니다.

1. 1단계에서 수집한 정보를 사용하여 비밀에 대한 책임 있는 팀을 찾아 비밀 유출에 대해 경고합니다.
2. 유출된 내용과 시기를 설명합니다. 비밀을 철회하고, 새 비밀을 생성해야 하며, 영향을 받는 서비스를 업데이트해야 한다고 설명합니다.
3. 리포지토리 관리자 및 보안 담당자에게 유출에 대해 알리고, 필요하거나 이미 수행된 모든 수정 작업을 설명합니다.
4. 원활한 전환을 조정하기 위해 적절한 팀과 함께 철회 및 회전 시간을 계획합니다.

위험 수준이 중간이거나 낮은 비밀이라도 유출될 경우 보안 및 규정 준수 모두에 위험을 초래할 수 있으므로 이를 수정하는 것이 중요합니다.

4단계 비밀 철회

코드베이스에서 비밀을 철회하는 것만으로는 충분하지 않습니다. 가장 중요한 수정 단계는 비밀 공급자를 사용하여 비밀을 철회하는 것입니다. 비밀을 철회하면 비밀이 악용될 가능성을 크게 줄일 수 있습니다.

1. 1단계에서 수집한 정보를 사용하여 비밀 공급자의 웹 사이트 또는 설명서를 찾습니다.

2. 비밀을 철회하기 위한 공급자의 지침을 따릅니다. 그렇게 하려면 일반적으로 공급자의 포털에 로그인하고 비밀이 관리되는 섹션으로 이동하는 작업이 포함됩니다.

   공급자 포털에 액세스할 수 없는 경우 비밀 소유자 또는 관련 리포지토리 관리자에게 문의하여 비밀 철회에 대한 도움을 받으세요.

3. 필요한 경우 새 비밀을 생성하여 철회된 비밀을 바꿉니다. 이는 원래 비밀에 의존하는 서비스의 기능을 복원하는 데 필요한 경우가 많습니다.

5단계: 영향을 받는 서비스 식별 및 업데이트

다음으로, 유출된 비밀을 사용하여 영향을 받는 모든 서비스에 대한 업데이트를 조정하고 이를 새 비밀로 업데이트해야 합니다.

식별

1. GitHub의 코드 검색을 사용하여 비밀에 대한 모든 코드, 문제, 끌어오기 요청을 확인합니다.
   • org:YOUR-ORG "SECRET-STRING"을 사용하여 조직 전체에서 검색합니다.
   • repo:YOUR-REPO "SECRET-STRING"을 사용하여 리포지토리를 검색합니다.
2. 리포지토리의 저장된 배포 키와 비밀 및 변수를 확인합니다.
   • “설정”을 클릭한 다음, “보안”에서 비밀 및 변수 또는 배포 키를 클릭합니다.
3. 설치된 GitHub Apps 및 비밀을 사용할 수 있는 통합을 확인합니다.

Coordinate

1. 영향을 받는 서비스 업데이트와 관련된 각 작업에 대한 문제(및 하위 문제)를 만들도록 Copilot에 지시합니다.
2. 여러 관계자가 관련되어 있는 경우 문제에 대한 프로젝트 보드를 만들어 진행 상황을 추적하고 커뮤니케이션을 용이하게 합니다.

업데이트 및 확인

1. 새 비밀로 애플리케이션을 업데이트하여 애플리케이션이 새 자격 증명을 제대로 사용하는지 확인합니다.

   팁

   애플리케이션에 중요한 자격 증명을 제공하는 안전한 방법은 개인 중요 보관소를 사용하는 것입니다. 예를 들어 리포지토리의 설정 페이지 아래에 있는 “비밀 및 변수” 저장소를 통해 GitHub 작업 및 워크플로에서 중요한 자격 증명을 사용할 수 있도록 설정할 수 있습니다.

2. 영향을 받는 서비스를 테스트하여 새 비밀로 제대로 작동하는지 확인합니다.

6단계. 무단 액세스 확인

서비스가 백업 및 실행되면 비밀이 노출되는 동안 발생했을 수 있는 무단 액세스를 확인하는 것이 중요합니다.

1. 비밀 및 해당 사용과 관련된 이벤트에 대한 GitHub의 감사 로그를 검토합니다.

   • 개인 계정의 보안 로그입니다. 보안 로그 검토을(를) 참조하세요.
   • 조직의 감사 로그입니다. 조직의 감사 로그 검토을(를) 참조하세요.
   • 엔터프라이즈의 감사 로그입니다. 엔터프라이즈에 대한 감사 로그 이벤트을(를) 참조하세요.

   조직 및 엔터프라이즈 수준 감사 로그의 경우 액세스 토큰과 관련된 이벤트를 구체적으로 검색할 수 있습니다. 액세스 토큰에 의해 수행되는 감사 로그 이벤트 식별(조직) 및 액세스 토큰에 의해 수행되는 감사 로그 이벤트 식별(엔터프라이즈)을(를) 참조하세요.

   GitHub의 감사 로그에 대한 액세스는 사용자의 역할에 따라 달라지므로 필요한 권한이 없는 경우 조직 소유자 또는 엔터프라이즈 관리자에게 문의해야 할 수 있습니다.

2. 비밀 공급자의 감사 로그를 검토합니다.

   • 예를 들어 AWS(Amazon Web Services) 비밀의 경우 유출된 비밀을 사용하여 CloudTrail 로그에서 무단 액세스 시도를 확인할 수 있습니다. AWS CloudTrail 설명서에서 AWS CloudTrail이란?을 참조하세요.

7단계. 리포지토리 정리

이제 코드베이스에서 비밀을 철회하고 업데이트했지만 비밀은 리포지토리의 커밋 기록에 여전히 존재할 수 있습니다. 이상적으로는 리포지토리에서 비밀의 모든 인스턴스를 검색하고 제거해야 합니다.

그러나 Git 기록을 정리하는 것은 리포지토리에 변경 내용을 강제로 푸시하는 작업을 포함할 수 있으므로 파괴적이고 중단적인 프로세스일 수 있습니다.

리포지토리의 보안 담당자와 함께 규정 준수 또는 보안 의무에 대해 리포지토리의 기록을 정리할 때 미치는 영향을 신중하게 고려해야 합니다. Removing sensitive data from a repository(리포지토리에서 중요한 데이터 제거)을(를) 참조하세요.

8단계: 경고 해결

1. 다음으로 닫기를 선택하고 경고를 “철회됨”으로 표시하여 리포지토리에서 secret scanning 경고를 닫습니다.
2. 유출을 수정하기 위해 수행된 단계와 얻은 교훈을 포함하여 팀의 기술 자료 또는 인시던트 관리 시스템에 인시던트를 문서화합니다.

9단계. 추가 유출 방지

비밀 유출 처리는 종종 중단되기 쉽고 복잡하며 시간이 많이 소요됩니다. 비밀 처리의 핵심은 항상 유출을 방지하는 데 있습니다.

1. 리포지토리에 대해 푸시 보호(GitHub Advanced Security의 일부)가 아직 설정되어 있지 않은 경우 이를 사용하도록 설정하세요. 신뢰할 수 있는 사용자만 푸시 보호를 무시할 수 있도록 엄격한 바이패스 컨트롤을 구현하는 방법을 살펴봅니다. 푸시 보호 정보을(를) 참조하세요.
2. 개인 계정에서 “사용자에 대한 푸시 보호”를 사용하도록 설정하여 지원되는 비밀을 모든 퍼블릭 리포지토리에 실수로 푸시하지 않도록 보호할 수 있습니다.
3. 팀 또는 조직 내에서 비밀 관리에 대한 모범 사례를 지원하거나 구현합니다.
   • 환경 변수를 사용하여 코드베이스에 하드 코딩하는 대신 비밀을 저장합니다.
   • 리포지토리의 설정 페이지 아래에 있는 GitHub의 “비밀 및 변수” 저장소와 같은 비밀 관리 도구를 사용하여 비밀을 안전하게 저장하고 관리합니다.
   • 잠재적인 유출의 영향을 최소화하기 위해 정기적으로 비밀을 회전합니다.
4. 인시던트 및 수정 단계를 문서화하는 것은 팀이 과거의 실수로부터 배우고 향후 사례를 개선하는 데 도움이 됩니다.
5. 정기적인 학습 및 보안 교육을 준수하고 수행합니다. 예를 들어 Microsoft Learn의 GitHub 고급 보안 과정을 참조하세요.

추가 참고 자료

• 비밀 검사 정보
• 푸시 보호 정보
• 지원되는 비밀 검사 패턴
• GitHub Advanced Security 정보