저장소에서 유출된 비밀 정보 복구하기

소개

API 키, 토큰, 인증 정보와 같은 비밀 정보는 코드베이스에 실수로 노출되거나 부적절하게 저장될 경우 팀과 조직에 심각한 보안 위험을 초래할 수 있습니다.

유출된 비밀 정보는 즉시 유출된 것으로 간주해야 하며, 비밀 정보의 사용 권한 취소와 같은 적절한 시정 조치를 취하는 것이 필수적입니다. 코드베이스에서 비밀 정보를 단순히 제거하거나, 새 커밋을 푸시하거나, 저장소를 삭제하고 재구성하는 것만으로는 비밀 정보가 악용되는 것을 막을 수 없습니다.

이 자습서에서는 실수로 리포지토리에 비밀을 커밋했거나 리포지토리에서 비밀 누출에 대한 경고를 받은 경우 수행할 작업을 안내합니다.

필수 조건

• 저장소에 최소한 쓰기 액새스 권한이 있습니다.
• 선택 사항: Secret scanning가 저장소에 활성화되었습니다.

  참고 항목

  Secret scanning는 공개 저장소에 대해 무료입니다. GitHub Advanced Security의 일부로 제공되며, GitHub Team 및 GitHub Enterprise Cloud 플랜의 비공개 저장소에서 사용할 수 있습니다.

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. 비밀번호를 취소하려면 공급자의 지침을 따르세요. 이는 일반적으로 공급자의 Portal에 로그인한 후 비밀번호가 관리되는 섹션으로 이동하는 과정을 포함합니다.

   제공자 Portal에 접근할 수 없는 경우, 비밀 소유자 또는 관련 저장소 관리자에게 연락하여 비밀을 취소하는 데 도움을 받으세요.

3. 필요한 경우, 취소된 비밀을 대체하기 위해 새로운 비밀을 생성하세요. 이는 원래 비밀에 의존하던 서비스의 기능을 복원하기 위해 종종 필요합니다.

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

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

Identify

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. 비밀 공급자의 감사 로그를 검토하세요.

   • 예를 들어, Amazon Web Services(AWS) 비밀 정보의 경우, 유출된 비밀 정보를 사용한 무단 접근 시도가 있는지 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 고급 보안 과정을 참조하세요.

추가 읽기

•         [AUTOTITLE](/code-security/secret-scanning/introduction/about-secret-scanning)
  

•         [AUTOTITLE](/code-security/secret-scanning/introduction/about-push-protection)
  

•         [AUTOTITLE](/code-security/secret-scanning/introduction/supported-secret-scanning-patterns)
  

•         [AUTOTITLE](/get-started/learning-about-github/about-github-advanced-security)