다음을 통해 공유

애플리케이션 비밀을 보호하기 위한 권장 사항

  • 아티클

이 Azure Well-Architected Framework 보안 검사 목록 권장 사항에 적용됩니다.

SE:09 스토리지를 강화하고 액세스 및 조작을 제한하고 해당 작업을 감사하여 애플리케이션 비밀을 보호합니다. 비상 시 회전을 즉석에서 수행할 수 있는 안정적이고 정기적인 회전 프로세스를 실행합니다.

이 가이드에서는 애플리케이션에서 중요한 정보를 보호하기 위한 권장 사항을 설명합니다. 비밀의 적절한 관리는 애플리케이션, 워크로드 및 관련 데이터의 보안 및 무결성을 유지하는 데 매우 중요합니다. 비밀을 부적절하게 처리하면 데이터 위반, 서비스 중단, 규정 위반 및 기타 문제가 발생할 수 있습니다.

API 키, OAuth(Open Authorization) 토큰 및 SSH(Secure Shell) 키와 같은 자격 증명은 비밀입니다. 클라이언트 쪽 OAuth 토큰과 같은 일부 자격 증명은 런타임에 동적으로 만들 수 있습니다. 동적 비밀은 일시적인 특성에도 불구하고 여전히 보호해야 합니다. 인증서 및 디지털 서명 키와 같은 비차원 정보도 중요할 수 있습니다. 규정 준수 요구 사항으로 인해 일반적으로 비밀로 간주되지 않는 구성 설정이 애플리케이션 비밀로 처리될 수 있습니다.

정의 

용어 정의
인증서 암호화 또는 암호 해독을 위해 공개 키를 보유하는 디지털 파일입니다.
자격 증명 통신 채널에서 게시자 또는 소비자의 ID를 확인하는 데 사용되는 정보입니다.
자격 증명 검사 비밀이 포함되지 않도록 소스 코드의 유효성을 검사하는 프로세스입니다.
암호화 데이터를 읽을 수 없게 만들고 비밀 코드로 잠기는 프로세스입니다.
키 암호화된 데이터를 잠그거나 잠금을 해제하는 데 사용되는 비밀 코드입니다.
최소 권한 액세스 작업 기능을 완료하기 위한 사용 권한 집합을 최소화하는 것을 목표로 하는 제로 트러스트 원칙입니다.
관리 ID 리소스에 할당되고 Azure에서 관리하는 ID입니다.
비보안 유출된 경우 워크로드의 보안 태세를 위태롭게 하지 않는 정보입니다.
회전 비밀이 손상된 경우 제한된 시간 동안만 사용할 수 있도록 정기적으로 비밀을 업데이트하는 프로세스입니다.
비밀 워크로드 구성 요소 간의 통신을 용이하게 하는 시스템의 기밀 구성 요소입니다. 유출된 경우 비밀로 인해 위반이 발생할 수 있습니다.
X.509 공개 키 인증서의 형식을 정의하는 표준입니다.

중요

비보안은 비밀처럼 취급하지 마세요. 비밀에는 비보안에 필요하지 않으며 추가 비용이 발생할 수 있는 운영 엄격함이 필요합니다.

애플리케이션에서 사용하는 API에 대한 URL과 같은 애플리케이션 구성 설정은 비보안의 예입니다. 이 정보는 애플리케이션 코드 또는 애플리케이션 비밀과 함께 저장하면 안 됩니다. Azure App Configuration 같은 전용 구성 관리 시스템을 사용하여 이러한 설정을 관리하는 것이 좋습니다. 자세한 내용은 Azure App Configuration?을 참조하세요.

주요 디자인 전략

비밀 관리 전략은 가능한 한 비밀을 최소화하고 플랫폼 기능을 활용하여 환경에 통합해야 합니다. 예를 들어 애플리케이션에 관리 ID를 사용하는 경우 액세스 정보는 연결 문자열에 포함되지 않으며 구성 파일에 정보를 저장하는 것이 안전합니다. 비밀을 저장하고 관리하기 전에 다음 관련 영역을 고려합니다.

  • 만든 비밀은 엄격한 액세스 제어를 사용하여 보안 스토리지에 보관해야 합니다.

  • 비밀 회전은 자동 관리 작업인 반면 해지는 반응적입니다.

  • 신뢰할 수 있는 ID만 비밀에 액세스할 수 있어야 합니다.

  • 비밀에 대한 액세스를 검사하고 유효성을 검사하려면 감사 내역을 유지해야 합니다.

ID 도용을 방지하고, 부인을 방지하고, 정보에 대한 불필요한 노출을 최소화할 수 있도록 이러한 지점을 중심으로 전략을 구축합니다.

비밀 관리에 대한 안전한 사례

가능하면 비밀을 만들지 마세요. 플랫폼에 책임을 위임하는 방법을 찾습니다. 예를 들어 플랫폼의 기본 제공 관리 ID를 사용하여 자격 증명을 처리합니다. 비밀이 적을수록 노출 영역이 줄어들고 비밀 관리에 소요되는 시간이 줄어듭니다.

키에는 사용자, 관리자 및 감사자의 세 가지 고유한 역할이 있는 것이 좋습니다. 역할 구분은 신뢰할 수 있는 ID만 적절한 수준의 권한을 가진 비밀에 액세스할 수 있도록 하는 데 도움이 됩니다. 개발자, 관리자 및 기타 관련 담당자에게 비밀 관리 및 보안 모범 사례의 중요성에 대해 교육합니다.

미리 공유된 키

각 소비자에 대해 고유한 키를 만들어 액세스를 제어할 수 있습니다. 예를 들어 클라이언트는 미리 공유된 키를 사용하여 타사 API와 통신합니다. 다른 클라이언트가 동일한 API에 액세스해야 하는 경우 다른 키를 사용해야 합니다. 두 소비자가 동일한 액세스 패턴 또는 역할을 가지고 있더라도 키를 공유하지 마세요. 소비자 범위는 시간이 지남에 따라 변경될 수 있으며 키를 공유한 후에는 권한을 독립적으로 업데이트하거나 사용 패턴을 구분할 수 없습니다. 고유 액세스는 해지를 더 쉽게 만듭니다. 소비자의 키가 손상된 경우 다른 소비자에게 영향을 주지 않고 해당 키를 해지하거나 회전하는 것이 더 쉽습니다.

이 지침은 다양한 환경에 적용됩니다. 사전 프로덕션 환경과 프로덕션 환경 모두에 동일한 키를 사용하면 안 됩니다. 미리 공유된 키를 만들 책임이 있는 경우 여러 클라이언트를 지원하기 위해 여러 키를 만들어야 합니다.

자세한 내용은 ID 및 액세스 관리에 대한 권장 사항을 참조하세요.

비밀 스토리지

Azure Key Vault 같은 비밀 관리 시스템을 사용하여 강화된 환경에 비밀을 저장하고, 미사용 및 전송 중 암호화하고, 비밀에 대한 액세스 및 변경 내용을 감사합니다. 애플리케이션 비밀을 저장해야 하는 경우 쉽게 회전할 수 있도록 소스 코드 외부에 보관합니다.

인증서는 Key Vault 또는 OS의 인증서 저장소에만 저장되어야 합니다. 예를 들어 PFX 파일 또는 디스크에 X.509 인증서를 저장하는 것은 권장되지 않습니다. 더 높은 수준의 보안이 필요한 경우 소프트웨어 기반 비밀 저장소 대신 HSM(하드웨어 보안 모듈) 기능이 있는 시스템을 선택합니다.

절충: HSM 솔루션은 더 높은 비용으로 제공됩니다. 추가된 보안 계층으로 인해 애플리케이션 성능에 영향을 미칠 수도 있습니다.

전용 비밀 관리 시스템을 사용하면 애플리케이션 비밀에 대한 액세스를 쉽게 저장, 배포 및 제어할 수 있습니다. 권한 있는 ID 및 서비스만 비밀 저장소에 액세스할 수 있어야 합니다. 권한으로 시스템에 대한 액세스를 제한할 수 있습니다. 권한을 할당할 때 항상 최소 권한 접근 방식을 적용합니다.

또한 비밀 수준에서 액세스를 제어해야 합니다. 각 비밀은 단일 리소스 scope 대한 액세스 권한만 가져야 합니다. 구성 요소가 필요한 비밀만 사용할 수 있도록 격리 경계를 만듭니다. 격리된 구성 요소가 손상된 경우 다른 비밀 및 잠재적으로 전체 워크로드를 제어할 수 없습니다. 비밀을 격리하는 한 가지 방법은 여러 키 자격 증명 모음을 사용하는 것입니다. 추가 키 자격 증명 모음을 만들기 위한 추가 비용은 없습니다.

비밀 액세스에 대한 감사 및 모니터링을 구현합니다. 비밀에 액세스하는 사용자와 권한이 없거나 의심스러운 활동을 식별할 시기를 기록합니다. 보안 관점에서 로깅에 대한 자세한 내용은 보안 모니터링 및 위협 탐지에 대한 권장 사항을 참조하세요.

비밀 회전

비밀 위생을 유지하는 프로세스를 마련하십시오. 비밀의 장수는 그 비밀의 관리에 영향을 미칩니다. 공격 벡터를 줄이려면 비밀을 사용 중지하고 가능한 한 자주 새 비밀로 대체해야 합니다.

OAuth 액세스 토큰을 신중하게 처리하여 라이브 시간을 고려합니다. 노출 기간을 더 짧은 기간으로 조정해야 하는지 고려합니다. 새로 고침 토큰은 애플리케이션에 대한 제한된 노출로 안전하게 저장되어야 합니다. 갱신된 인증서도 새 키를 사용해야 합니다. 새로 고침 토큰에 대한 자세한 내용은 보안 OAuth 2.0 On-Behalf-Of 새로 고침 토큰을 참조하세요.

비밀은 수명이 다한 후, 워크로드에서 더 이상 사용되지 않거나 손상된 경우 바꿉니다. 반대로, 비상 사태가 아니면 활성 비밀을 사용 중지하지 마세요. 액세스 로그를 확인하여 비밀의 상태 확인할 수 있습니다. 비밀 회전 프로세스는 워크로드의 안정성 또는 성능에 영향을 주지 않아야 합니다. 원활한 회전을 위해 비밀, 소비자 및 액세스 방법에서 중복성을 구축하는 전략을 사용합니다.

Azure Storage에서 회전을 처리하는 방법에 대한 자세한 내용은 계정 액세스 키 관리를 참조하세요.

회전 프로세스는 사람이 상호 작용하지 않고 자동화하고 배포해야 합니다. 기본적으로 회전 개념을 지원하는 비밀 관리 저장소에 비밀을 저장하면 이 작업 작업을 간소화할 수 있습니다.

비밀 사용에 대한 안전한 사례

비밀 생성기 또는 연산자는 안전한 방식으로 비밀을 배포할 수 있어야 합니다. 많은 조직에서 도구를 사용하여 organization 내외부에서 안전하게 비밀을 파트너와 공유합니다. 도구가 없는 경우 권한 있는 받는 사람에게 자격 증명을 제대로 전달하는 프로세스가 있습니다. 재해 복구 계획에는 비밀 복구 절차가 포함되어야 합니다. 키가 손상되거나 유출되어 요청 시 다시 생성되어야 하는 상황에 대한 프로세스를 갖습니다. 비밀을 사용할 때 안전을 위한 다음 모범 사례를 고려합니다.

하드코딩 방지

애플리케이션 코드, 구성 파일 및 빌드 배포 파이프라인과 같은 코드 아티팩트에서 정적 텍스트로 암호를 하드 코드하지 마세요. 이 고위험 사례는 비밀이 읽기 액세스 권한이 있는 모든 사람에게 노출되기 때문에 코드를 취약하게 만듭니다.

관리 ID를 사용하여 자격 증명을 저장할 필요가 없으므로 이러한 상황을 방지할 수 있습니다. 애플리케이션은 할당된 ID를 사용하여 IdP(ID 공급자)를 통해 다른 리소스에 대해 인증합니다. 개발 중에 가짜 비밀을 사용하여 비프로덕션 환경에서 테스트하여 실제 비밀이 실수로 노출되는 것을 방지합니다.

애플리케이션 코드에서 노출된 비밀을 주기적으로 검색하고 아티팩트 빌드 도구를 사용합니다. 소스 코드 커밋이 배포되기 전에 자격 증명을 검색하는 Git 사전 커밋 후크로 이러한 도구를 추가할 수 있습니다. 애플리케이션 로그를 정기적으로 검토하고 삭제하여 실수로 기록되는 비밀이 없는지 확인합니다. 피어 검토를 통해 검색을 강화할 수도 있습니다.

참고

검사 도구에서 비밀을 검색하는 경우 해당 비밀은 손상된 것으로 간주되어야 합니다. 취소해야 합니다.

비밀 회전에 응답

워크로드 소유자는 사용자에게 최소한의 중단으로 새 비밀을 통합할 수 있도록 비밀 회전 계획 및 정책을 이해해야 합니다. 비밀이 회전되면 이전 비밀이 유효하지 않지만 새 비밀이 배치되지 않은 창이 있을 수 있습니다. 이 기간 동안 애플리케이션이 도달하려는 구성 요소는 요청을 승인하지 않습니다. 코드에 재시도 논리를 빌드하여 이러한 문제를 최소화할 수 있습니다. 서로에 영향을 주지 않고 안전하게 변경할 수 있는 여러 자격 증명을 가질 수 있는 동시 액세스 패턴을 사용할 수도 있습니다.

운영 팀과 협력하여 변경 관리 프로세스의 일부가 됩니다. 더 이상 필요하지 않은 자격 증명을 사용하는 애플리케이션의 일부를 해제할 때 자격 증명 소유자에게 알려야 합니다.

비밀 검색 및 구성을 자동화된 배포 파이프라인에 통합합니다. 비밀 검색은 배포 중에 비밀이 자동으로 페치되도록 하는 데 도움이 됩니다. 비밀 삽입 패턴을 사용하여 런타임에 애플리케이션 코드 또는 구성에 비밀을 삽입하여 비밀이 실수로 로그 또는 버전 제어에 노출되지 않도록 할 수도 있습니다.

Azure 촉진

Key Vault 사용하여 비밀을 저장합니다. Azure 비밀 관리 시스템, Key Vault, Azure Managed HSM 및 기타 위치에 비밀을 저장합니다. 자세한 내용은 올바른 키 관리 솔루션을 선택하는 방법을 참조하세요.

ID 기반 액세스 제어를 통합합니다. Microsoft Entra ID 및 관리 ID를 사용하면 비밀의 필요성을 최소화할 수 있습니다. Microsoft Entra ID는 키 회전, 변칙 등을 처리하기 위한 기본 제공 메커니즘을 사용하여 액세스 제어에 매우 안전하고 사용 가능한 환경을 제공합니다.

Azure RBAC(역할 기반 액세스 제어)를 사용하여 특정 scope 사용자, 그룹 및 애플리케이션에 권한을 할당합니다.

액세스 모델을 사용하여 키 자격 증명 모음, 권한 및 비밀을 제어합니다. 자세한 내용은 액세스 모델 개요를 참조하세요.

비밀 노출 검색을 구현합니다. 의심스러운 활동을 감지하고 애플리케이션 코드에서 노출된 키에 대해 주기적으로 검사 워크로드에 프로세스를 통합합니다. 이러한 옵션에는 다음이 포함됩니다.

애플리케이션 구성 파일 또는 CI/CD(연속 통합 및 지속적인 업데이트) 파이프라인에 환경 유형에 대한 키와 비밀을 저장하지 마세요. 개발자는 Visual Studio 연결된 서비스 또는 로컬 전용 파일을 사용하여 자격 증명에 액세스해야 합니다.

보안 검사 목록

전체 권장 사항 집합을 참조하세요.

보안 검사 목록