응용 프로그램에 필요한 자격 증명을 저장하는 방법은 무엇입니까?

모든 사람들은 버전 제어 (git)에 자격 증명을 저장하는 것이 좋지 않다고 말합니다. 따라서 훨씬 더 나은 자격 증명을 저장하는 다른 방법이 있어야합니다.

응용 프로그램이 의존하는 서비스를 사용하려면 어딘가에서 자격 증명을 받아야합니다. 이러한 자격 증명은 일반적으로 구성 파일에 저장됩니다. 서버가 사람의 개입없이왔다 갔다하기 때문에 파일을 생성하기 위해 각 서버를 수동으로 입력하는 것은 문제가되지 않습니다.

응용 프로그램의 자격 증명을 관리하는 방법은 무엇입니까?

애플리케이션의 비밀을 올바르게 관리하는 것은 항상 어려운 일이었습니다. 클라우드 도입으로 새로운 과제가 발생했습니다. 클라우드에 비밀을 저장하는 현실과 과제에 대한 훌륭한 OWASP 프레젠테이션 이 있습니다 .

비밀을 소스 코드에 저장하는 것이 제시된 솔루션 (또는 "아키텍처") 중 하나라는 사실에 놀랄 수도 있습니다. 현재로서는 완벽한 아키텍처 나 방법이 없기 때문입니다. 결국, 당신의 비밀은 암호화 될 수 있습니다 ...하지만 암호화 키를 보호하는 것은 무엇입니까? "거북이 끝까지"라고 그들은 말했다.

모든 유형의 비밀 관리에는 강점과 약점이 있으며 프레젠테이션은 이미 그 내용을 다룹니다. 대신 비밀 (자격 증명) 관리 솔루션에서 찾고있는 일부 기능을 살펴 보도록하겠습니다.

• 액세스 제어 : 관리자에게 쓰기 권한을 부여하고 애플리케이션에 대한 읽기 권한을 부여 할 수 있습니까? 읽을 수있는 응용 프로그램을 제한 할 수 있습니까 (응용 프로그램 A는 이러한 비밀에만 액세스 할 수 있음)?
• 감사 로그 : 많은 규정 준수 보고서에 필요하며 문제가 있는지 확인하는 좋은 방법
• 비밀의 안전한 저장 : 솔루션은 비밀을 어떻게 저장합니까? 암호화 된 DB? 암호화 된 FS? 암호화 키가있는 경우 누가 / 무엇을 보유합니까? 시작시 한 번 안전하게 폐기 된이 키는 어떻게 사용됩니까?
• 키 / 암호 순환 또는 갱신 : 비밀이 손상되면이를 취소하고 업데이트 된 비밀을 응용 프로그램에 보낼 수 있습니까? 응용 프로그램이 비밀 관리 서비스를 풀링 할 수 있습니까?
• 호환성 :이 솔루션 중 일부는 특정 언어 또는 프레임 워크와 긴밀하게 통합됩니다. 일부는 REST API를 제공합니다. 이것에 관심이 있습니까?

이러한 항목을 살펴보고, 귀하에게 중요한 사항과 솔루션에 의해 구현되는 방법 을 통해 비밀 관리 서비스 중 하나 를 선택할 수 있습니다 .

순전히 EC2 기반 환경의 경우 가장 쉬운 솔루션은 AWS IAM 역할 및 S3 버킷 정책을 사용하는 것입니다. 이 패턴의 일부 공식에는 스토리지 용 S3 대신 암호화 용 KMS 및 DynamoDB도 포함되어 있지만 어느 것도 사용해야 할 큰 이유는 없습니다. https://github.com/poise/citadel을 확인하십시오. 특히 Chef 사용자를 대상으로하지만 기본 패턴은 무엇이든 작동하므로 S3에서 실제 다운로드를 수행하기 위해 자체 도우미를 만들어야 할 수도 있습니다.