비밀을 소스 제어에서 제외-문제를 해결하고 있습니까?

App.config 및 유사한 파일에서 비밀이 소스 제어 상태 인 일부 프로젝트를 상속했습니다. 다행스럽게도 공용 저장소가 아니기 때문에 위험이 심각하지 않았습니다. Azure KeyVault와 같이이를 관리하는 더 나은 방법을 찾고 있습니다. (그러나 나는이 질문이 그 해결책에만 국한되지는 않는다.)

일반적으로 우리는 단지 문제를 옮기는 것이 아닙니까? 예를 들어 Azure KeyVault를 사용하면 앱 ID와 앱 비밀이 소스 제어에서 유지해야하는 것이됩니다. 불행히도 이것이 어떻게 잘못되는지에 대한 전형적인 예가 있습니다. 다른 접근 방식은 보호해야하는 API 키 또는 키 저장소 파일과 비슷합니다.

Azure KeyVault와 같은 제품은 비밀을 별도의 구성 파일에 보관 하고 .gitignore 또는 동등한 파일 인지 확인하는 것보다 낫지 않고 더 복잡하지 않습니다 . 이 파일은 필요에 따라 사이드 채널을 통해 공유해야합니다. 물론 사람들은 아마 서로에게 안전하지 않은 이메일을 보낼 것입니다 ...

문제를 옮기지 않는 비밀을 관리 할 수있는 방법이 있습니까? 나는이 질문에 명확하게 정의 된 단일 답변이 있다고 생각합니다. 유추하여 HTTPS가 어떻게 문제를 해결하지 않는지 묻는다면 CA 키가 OS와 함께 배포되며 OS의 배포 방법을 신뢰하기 때문에 신뢰합니다. (우리가 별도의 질문을 해야하는지 여부 ...)

문제를 해결하고 있다고 말할 수 있습니다. 궁극적으로 암호, ssh 키 등을 가지려면 앱이 액세스 할 수있는 곳에 비밀 정보가 저장되어 있어야합니다.

그러나 올바르게 수행하면 제대로 보호하기 어려운 곳에서 더 잘 보호 할 수있는 곳으로 문제를 옮길 수 있습니다. 예를 들어, 공개 github 저장소에 비밀을 넣는 것은 집 열쇠를 현관에 테이프로 두는 것과 거의 같습니다. 원하는 사람은 찾는 데 어려움이 없습니다. 그러나 외부 연결이없는 내부 네트워크의 키 저장소로 이동하면 암호를 안전하게 유지할 가능성이 훨씬 높아집니다. 그것은 주머니에 열쇠를 보관하는 것과 같습니다. 잃어 버릴 수는 없지만 (예를 들어 Azure 암호를 제공하는 것과 동일), 키를 문에 두는 것보다 노출을 제한합니다.

몇 가지 이유로 암호화 키 및 자격 증명과 같은 비밀을 소스 제어에 체크인해서는 안됩니다. 첫 번째는 암호화 키와 자격 증명을 항상 알아야 할 필요가 있으며 소스 제어는 정보가 공개되지 않도록 신뢰할 수있는 방법이 아닙니다. 소스 제어에서 이러한 비밀을 원하지 않는 다른 이유는 일반적으로 비밀이 일반적으로 응용 프로그램이 실행될 환경의 특정 속성에 따라 다르기 때문입니다 (예 : 항상 그런 것은 아님). 웹 서비스 인증에 필요한 서명 인 경우 해당 웹 서비스의 특정 엔드 포인트가 QA 서명이 필요한 QA 환경에서 실행될 수 있습니다.

환경 (또는 글로벌 비밀)을 처리하는 올바른 방법은 다른 환경 구성 속성과 마찬가지로 환경을 적절하게 처리하는 것입니다. 잘 디자인되고 독립적이며 버전을 지정할 수있는 코드 모듈은 응용 프로그램에 속성 (예 : 데이터베이스 연결 세부 정보, 자격 증명, 웹 서비스 끝점, 파일 경로 등)을 알리기 위해 배포 된 환경과 동일하게 환경에서 동일해야합니다. 응용 프로그램에 중요한 구성 세부 사항은 외부화되어 환경의 구성 매개 변수가됩니다.

이제 몇 가지 논증을 다루기 위해 :

일반적으로 우리는 단지 문제를 옮기는 것이 아닙니까?

완벽한 보안과 같은 것은 없지만 추가 조치와 통제가 가능한 영역으로 문제를 "이동"하면 난이도가 향상되고 우발적이거나 악의적 인 비밀의 공개 가능성이 줄어 듭니다. 기밀 데이터를 보호해야하는 시스템을 설계 할 때 따라야 할 규칙은 항상 두 가지로 제어하는 ​​것입니다. 이것이 의미하는 바는 기밀 정보 또는 보안 사고의 우발적 또는 악의적 인 공개가 발생하기 위해서는 실패 또는 둘 이상의 통제가 있어야한다는 것입니다.

이에 대한 좋은 예는 서버에 암호화 된 파일을 저장하는 것일 수 있습니다. 또한 다른 파일에 기밀로 유지해야하는 비밀 암호 해독 키가 있습니다.

• 키와 암호화 된 파일을 동일한 서버에 저장하십시오 (0 제어, 서버에 대한 액세스 권한이있는 사람은 누구나 기밀 정보를 얻을 수 있음)
• 위의 단계를 수행하고 OS의 응용 프로그램 런타임 사용자 만 읽을 수 있도록 두 파일에 대한 파일 액세스를 보호하십시오 (1 개의 제어, 루트 사용자의 암호를 손상 시키거나 응용 프로그램 런타임 사용자는 공격자가 기밀 정보를 얻을 수 있음)
• 외부 키 저장소에 키를 저장하고 IP 주소 화이트리스트, 인증서 인증 및 파일 시스템의 암호화 된 파일에 액세스 할 수있는 애플리케이션에 대한 기타 조치와 같은 여러 가지 보안 조치를 사용하여 키를 확보하십시오. (여러 통제, 기밀 데이터가 손상 되려면 여러 가지 보안 통제 실패가 발생해야 함)

다시 말하지만 완벽한 보안과 같은 것은 없지만 여러 컨트롤을 사용한다는 목표는 공개가 발생하기 위해 여러 가지 실패가 발생하도록 보장합니다.

Azure KeyVault와 같은 제품은 더 나쁘지 않으며 무의미하게 더 복잡해 보입니다.

무의미한 것은 완전히 주관적입니다. 기밀 데이터가 노출되는 것이 얼마나 심각한지를 실제로 고려하지 않으면 추가 보안의 무의미함에 대해 토론 할 수 없습니다. 기밀 데이터를 사용하여 금융 기관에서 불법 송금을 보낼 수 있다면 주요 금고와 같은 것이 무의미한 것보다 먼 것입니다.

비밀을 별도의 구성 파일에 보관하고 .gitignore 또는 동등한 파일인지 확인하십시오.

누군가 실수로 소스 제어에 체크인 할 때까지 비밀은 소스 제어 히스토리에 영원히 포함됩니다.

물론 사람들은 아마 서로에게 안전하지 않은 이메일을 보낼 것입니다 ...

보안은 기술적 인 문제 일뿐만 아니라 사람의 문제이기도합니다. 그것은 주제에서 벗어난 것이지만, 나는이 시점에서 당신이 필요한 것을하지 말고 자신을 이야기하려고한다고 생각합니다.

문제를 옮기지 않는 비밀을 관리 할 수있는 방법이 있습니까? 나는이 질문에 명확하게 정의 된 단일 답변이 있다고 생각합니다. 유추하여 HTTPS가 어떻게 문제를 해결하지 않는지 묻는다면 CA 키가 OS와 함께 배포되며 OS의 배포 방법을 신뢰하기 때문에 신뢰합니다.

보안이 항상 문제를 해결하는 것은 아니며, 많은 시간을 제어 할 수 있습니다. 사실 공개-개인 키 암호화가 정확히하는 일이기 때문에 당신의 비유는 간결합니다. 우리는 공공 인증서를 소유 한 실체의 신원을 보증하기 위해 CA를 완화하고 완벽하게 신뢰함으로써 CA에 "문제를 옮기고 있습니다". 기본적으로 보안 문제로 이어질 수있는 치명적인 오류 문자열 (예 : CA에 대한 신뢰 상실)이 발생하지 않아야합니다.

많은 것들과 마찬가지로 보안은 주관적인 기준, 데이터의 성격, 공개의 결과, 위험 식욕, 예산 등을 기반으로 그리는 선입니다.

git repo의 비밀 파일을 비대칭 키로 암호화하려면 git secret프로젝트 ( http://git-secret.io/ ) 를 고려해야 합니다. 공개 키도 저장소에 있으며 개인 키는 없습니다.

이 방법의 특징은 다음과 같습니다.

• 새 사용자 / 컴퓨터가 보안 파일을 해독해야하는 경우 공개 gpg (gnu privacy guard aka pgp) 키를 게시 / 보냅니다. 보안 파일을 이미 해독 할 수있는 사용자는 새로운 추가 키로 파일을 다시 암호화 할 수 있습니다. 새 사용자는 개인 키로 보안 파일을 해독 할 수 있습니다.
• 분명히 git 저장소에 커밋 / 푸시 할 수있는 사람을 제어해야합니다. 그렇지 않으면 공격자는 자신의 공개 키를 커밋하고 권한이 부여 된 누군가가이 새로운 공개 키로 보안 파일을 다시 암호화 할 때까지 기다릴 수 있습니다.