서버 환경 변수에 중요한 암호를 저장하는 것이 안전합니까?

중요한 클러스터 미션 크리티컬 시스템 (메시지 큐, 데이터 저장소 및 기타 서비스)에 대한 일반 텍스트 비밀번호가 각각 포함 된 구성 파일이있는 서버 클러스터가 있습니다.

어떤 사람들은 구성 파일에서 중요한 암호를 서버 프로세스가 실행되는 사용자 계정의 환경 변수로 옮깁니다. 이러한 방식으로 구성 파일을 버전 제어로 커밋 할 수 있으며 시스템 관리자는 서버 시스템을 설정할 때 적절한 환경 변수 만 작성하면됩니다. 당연히 이러한 서비스를 실행하는 계정에 대한 액세스는 매우 제한적입니다.

이것이 일반 텍스트 구성 파일에서 암호를 피하는 가장 좋은 방법입니까, 아니면 더 좋은 방법이 있습니까?

Linux 시스템을 사용하는 경우 / proc / * / environ을보고 환경 변수가 중요한 정보를 저장하기에 적합한 장소인지 결정하십시오. / proc / self는 현재 프로세스입니다.

$ tr '\0' '\n' < /proc/self/environ
USER=me
LOGNAME=me
HOME=/home/me
PATH=/usr/bin:/bin:/usr/sbin:/sbin
MAIL=/var/mail/me
SHELL=/usr/bin/sh
SSH_CLIENT=1.2.3.4 58195 22
SSH_CONNECTION=1.2.3.4 58195 7.8.9.0 22
SSH_TTY=/dev/pts/1
TERM=xterm

환경 변수를 설정하는 것은 아마도 어딘가에서 파일을 읽는 것입니다.

기억해야 할 것은 암호를 사용하면 프로그램에서 암호를 사용할 수 있다는 의미입니다. 프로그램에서 필요할 때마다 사용자가이 암호를 입력하지 않으면이 암호는 프로그램의 액세스 권한에 따라 액세스 할 수 있어야합니다. 암호를 로컬로 암호화하고 키를 사용하여 프로그램의 암호를 해독하도록 할 수 있지만 실수로 공개되지 않도록 암호를 가릴뿐입니다. 프로그램과 동일한 액세스 권한을 가진 사람은 프로그램이 수행 할 수있는 것과 동일한 작업을 수행 할 수 있으며 여기에는 암호화 키 읽기가 포함됩니다.

올바른 방법은 응용 프로그램을 제한된 계정으로 실행하고 파일 시스템 수준 권한으로 보호되는 파일에 암호를 저장하는 것입니다. VCS에 보안 제어가 없다고 가정하면 암호를 버전 제어 시스템에서 유지하기 위해 파일 또는 이와 유사한 파일을 "포함"할 수 있기를 바랍니다. 의도하지 않은 공개를 방지하려면 원하는 암호를 숨기십시오. base64로 인코딩하고 pgp를 사용하여 서버 프로그램의 옵션 세트에 의미가있는 암호를 사용하십시오. 이 작업을 수행하는 프로그램을 작성하는 경우 필요한 경우에만 사용자에게 암호를 묻는 메시지를 표시 한 다음 암호를 사용하자마자 메모리에서 제거하는 것이 가장 좋습니다.

당신이 요구하는 것을 모든 데이터가있는 경우 궁극적으로 읽을 뿐만 아니라로 작성 , 당신은 (또는 당신이 있다면 암호로 뭔가를 보호 끝날거야 정말 물리적 하드웨어 스마트 카드와 PIN으로, 편집증), 아니 얼마나 많은 암호화 계층이 있는지.

이것은 시스템 보안과 편의성의 기본 문제로 요약됩니다. 악의적 인 행위자가 "선점"에 도달하기 위해 위반해야 할 보안 통제 계층이 많고 "심층 방어"를 추가 할 수 있지만 합법적 인 행위자가 일부 데이터를 읽거나 변경하려는 경우, 그들은 많은 농구대를 통과해야합니다. 대안은 텍스트 파일의 일반 텍스트 비밀번호입니다.

미션 크리티컬 시스템에서 일부 정보를 실제로 보호하려는 경우 수행 할 작업 :

1. 전체 영구 저장소의 내용이 암호화되도록 전체 디스크 암호화를 사용하십시오.

2. 기계에 대한 물리적 접근을 제한하십시오. 안전한 잠금 장치로 기계의 섀시를 잠그고 키에 대한 물리적 접근을 제어하십시오. 출입을 위해 게이트 키퍼가 될 근육 (무장 경비원)을 고용하십시오.

3. 장치의 운영 체제에서 세분화 된 필수 액세스 제어 (MAC)를 시행하십시오. GNU / Linux에서 SELinux와 같은 것으로 시작하여 Enforcing으로 설정 한 다음 프로덕션 소프트웨어의 정확한 요구에 맞게 정책을 조정하여 필요한 계정에 필요한 파일에 대한 권한을 정확하게 허용 할 수 있습니다.

4. 시스템 고유의 비밀번호와 구성 파일의 버전 제어를 사용하려는 경우 실수로 일반 텍스트 비밀번호가 버전 제어에 커미트되어 실수로 유출 된 비밀번호를 찾기가 어려울 수 있으므로 실수를 피하려고합니다. VCS의 캐시. 환경 변수는 여러 가지 가능한 옵션 중 하나입니다. 다른 하나는 프로그램이 시작될 때 암호 프롬프트이지만 기계를 재부팅하고 작동 상태를 복원하는 것은 수동 노력이며 자율적으로 수행 할 수 없으므로 편의성 대 보안이 다시 있습니다.

5. 네트워크를 통한 공격에 대한 노출을 최소화하기 위해 방화벽 권한을 관리 할 수있는 네트워킹 전문가가 있는지 확인하십시오. 외부 시스템, 특히 공용 인터넷과 인터페이스하는 모든 소프트웨어를 감사 (침투 테스트 및 화이트 박스 테스트 코드)합니다. "인터페이스"에는 직접 네트워크 연결뿐만 아니라 "신뢰할 수없는"데이터 (보안 서버의 RAM / 디스크 / CPU 외부에서 바이트가 발생한 데이터)를 읽거나 쓰는 것도 포함됩니다.

이것은 완전한 목록은 아니지만, 특히 포인트 4는 아마도 당신과 관련이 있지만, 적어도 1 ~ 3 단계를 수행하지 않으면 포인트 4와 포인트 5를 고려하면별로 도움이되지 않습니다. 시스템은 상당히 근본적인 수준에서 안전하지 않습니다.

환경 변수에 암호를 전달하는 것은 프로그램이 파일에서 암호를 읽는 것만 큼 안전합니다. 동일한 사용자로 실행중인 프로세스 만 프로세스 환경 을 읽을 수 있으며 이러한 프로세스는 어쨌든 동일한 파일을 읽을 수 있습니다.

이것은 명령 행에서 비밀번호를 전달하는 것과 다릅니다. 명령 줄 인수는 동일한 사용자로 실행되는 프로세스뿐만 아니라 동일한 시스템에서 실행중인 모든 프로세스 (강화 조치 제외)에서 읽을 수 있습니다.

환경을 통해 변수를 전달하는 경우 프로그램이 다른 프로그램을 시작하는지주의하십시오. 다른 프로그램은 부모의 환경을 상속받습니다. 다른 프로그램이 우연히 자신의 환경 내용을 유출 할 우려가있는 경우에는이 작업을 수행하지 마십시오.

시나리오의 결함은 "서버 시스템 설정시 적절한 환경 변수 작성"입니다. 환경 변수는 프로세스의 동적 속성입니다. 시스템을 설정할 때 시스템을 만들 수는 없습니다. 설정을 통해 재부팅해도 살아남을 수있는 것은 아닙니다. 의미하는 것은 아마도 특정 사용자가 로그인 할 때 관리자가이 변수가 환경에 존재하도록 구성한 것입니다. 이는 구성 파일 (일반적으로 ~/.pam_environment또는 ~/.profile에서 읽은 파일)을 통해 수행됩니다 ~/.profile. 따라서이 솔루션은 실제로 구성 파일에서 비밀번호를 이동하지 않습니다.

암호가 사용자의 로그인 시간 환경에 있도록 설정하는 것은 좋은 생각이 아닙니다. 즉, 해당 사용자로 실행중인 모든 프로세스에는 비밀이 있으므로 어디에서나 누수에 취약합니다.

암호는 버전 관리를받는 구성 파일과 일반적인 배포 메커니즘을 제외한 파일에 보관해야합니다. 편리한 경우 환경에 암호를 입력해도 괜찮지 만 가능한 한 작은 프로그램 집합에 대해 수행해야합니다.