우리는 구성/배치/빌드 스크립트 (fabfile.py, circle.yml, Dockerfile 등)와 함께 (git에서) 코드를 사용하여 자동으로 빌드/배포 프로세스를 완벽하게 수행합니다. 이음새가없는 부분은 다양한 종류의 자격 증명을 저장할 위치입니다. 이것은 ssh 키, 코드 서명 인증서, aws 액세스 키, SSL 인증서와 같은 것들입니다 ... 현재 프로세스는 플래시 드라이브에서 필요한 키/인증서를 복사 한 다음 (예 : 패브릭을 실행하는 것입니다)devops에 대한 자격 증명을 저장할 위치는 어디입니까?
git (코드 옆에)와 같은 자격 증명을 저장하는 것이 가장 좋은 장소가 아닌 것 같습니다.하지만 무엇이 이일까요? devops에 대해 이와 같은 정보를 저장할 위치에 권장되는 우수 사례가 있습니까? 거기에 장단점과 다른 옵션을 설명하는 참조가 있습니까?
예. 추천이 있습니다. Cloud Vault의 사용법입니다. 좋은 예를 살펴 보자 :
https://www.hashicorp.com/blog/vault.html
https://blog.keepersecurity.com/2016/08/16/keeper-for-devops-more-than-just-passwords/
비밀 관리의 문제는 아직 정확히 어떤 도구를 사용하여 "해결"되지 않은 무언가이다.
다양한 비밀 관리 도구 (각각 다른 유형의 혜택/통합 기능 제공) 중 하나를 사용할 수 있습니다.
저는 개인적으로 Hashicorp Vault를 선호합니다. Cyberark는 또 다른 좋은 것입니다.
그러나 솔루션에서 이러한 도구를 사용하는 방법에는 몇 가지 공통적 인 사용 패턴이 있습니다.
1) 코드가 암호화되어있는 경우 SCM에 코드에 암호를 저장할 수 있습니다 ... 그러나 여전히 같은 문제가 발생하지만 배포시 안전하게 비밀리에 제공해야합니다 (또는 시작시 사용할 수 있도록해야합니다)을 사용하여 배포 된 비밀 (암호, 자격 증명, 비밀, 인증서)을 해독 할 수 있습니다. 비밀 관리 도구 (예 : Vault)가 들어오는 곳입니다.이 도구를 사용하면 필요한 경우 비밀 정보를 안전하게 해독 할 수 있습니다.
2) 위에서 언급 한 다른 방법이 있습니다. 실제로 비공개 관리 도구 자체에 SCM 외부의 모든 비밀, 인증서 등을 저장하고 배포/시작시 검색합니다.
분명히 어떤 일을하는 것이 장단점이 있습니다. 즉, 첫 번째 접근 방식은 주어진 시간에 한 두 가지 비밀 만 관리 할 때 복잡성을 줄입니다. 반면에 모든 비밀을 저장소에 저장하면 단일 비밀에 대한 액세스로 다른 모든 비밀에 대한 액세스가 허용되지 않으므로 전체 생태계와 관련된 손상 가능성이 줄어 듭니다.
하루가 끝나면 사용 가능한 보안 구조와 사용 가능한 보안 구성 요소가 모두 포착됩니다. 결국 누군가가 어딘가 비밀을 알아야하기 때문에 ...