☰

프로세스의 환경 변수가 노출되지 않도록 보호

tag-icon • tag-icon permissions security configuration environment-variables
프로세스의 환경 변수가 노출되지 않도록 보호

웹 애플리케이션 개발에 대한 현재 모범 사례를 읽었습니다(예:12가지 요소 가이드) 구성 데이터를 저장하는 권장 방법은 다음과 같습니다.환경 변수. 이는 종종 실수로 프로젝트 저장소에 체크인하여 "코드/구성" 분리를 깨고 잠재적으로 비밀(예: API 키, 솔트 등)을 노출시키는 구성 파일에 보관하는 것과는 대조적입니다.

그러나 내가 해결하지 못한 것은 우발적인 노출을 방지하는 문제입니다. 구성 파일을 사용할 때 특정 사용자를 제외한 누구도 비밀 구성을 읽지 못하도록 파일 권한을 적절하게 설정할 수 있습니다. 그러나 Unix 시스템은 프로세스의 환경 변수에 대해 이러한 보호 기능을 제공하지 않는 것 같습니다. 프로세스가 다른 사용자에 의해 시작된 경우에도 마찬가지입니다.

$ sudo -u root x=5 sleep 30
$ ps au -E | grep sleep  # in different terminal
root 53814 s003  S+     0:00.01 sudo -u root x=5 sleep 30

변수에 민감한 데이터가 포함되어 있는 경우 x임의의 사용자(꼭 루트나 스누핑하려는 프로세스를 시작한 사용자일 필요는 없음)로 로그인한 시스템에 액세스하여 간단히 읽을 수 있습니다. 따라서 이 구성 방법은 환경 변수를 어떻게든 보호할 수 없는 한 구성 파일보다 덜 안전해 보입니다(심층 PoV 관점에서 볼 때 당연히 머신은 무단 액세스로부터 보호되어야 함).

ps a -E그래서 내 질문은: 동일한 Unix 시스템의 다른 사용자가 ( 및 기타 가능한 수단을 통해) 프로세스의 환경 변수를 보지 못하도록 하는 방법이 있습니까 ?

답변1

첫째, 좋은 질문입니다!

이 -E스위치는 프로세스가 시작되었을 때만 환경을 표시하므로 변경 사항은 이 메서드에 표시되지 않습니다. 따라서 프로세스 시작 후 환경에 데이터가 로드되면 이 방법으로는 검색되지 않습니다. 그러나 IMHO는 아래에 설명된 이유로 인해 실행 가능한 전략이 아닐 수 있습니다.

나는 환경 변수 트릭이 좋은 방법이라는 Twelve Factor의 의견에 동의합니다. 그러나 12가지 요소 가이드에 설명되지 않은 몇 가지 중요한 고려 사항은 물론 이 목표를 달성하기 위한 몇 가지 실질적인 고려 사항 및 기술도 있습니다.

첫째, 환경 변수는 휘발성(비지속적)입니다. 다시 시작하면 모든 데이터가 손실됩니다. 즉, 구성하면아니요어딘가에 남아 있으면 시스템 관리자의 메모리에 있지 않는 한 서버를 재부팅할 때 복구할 수 없습니다 /dev/brain0(128비트 키로 도박을 하지는 않습니다). 이것이 서버의 개인 키인 경우 기껏해야 큰 문제가 있고 최악의 경우에는 치명적인 문제가 됩니다(CA에서 키를 재발급해야 할 수도 있음). 이는 어딘가에 구성을 작성해야 하는 좋은 예이며 많은 사람들이 이에 대해 이의를 제기하지 않을 것이라고 생각합니다. 그러나 중요한 것은 어디에/어떻게 저장되는지입니다.

Twelve Factor 앱은 직접적인 방법은 아니지만 이 문제를 해결합니다. "애플리케이션이 코드에서 모든 구성을 올바르게 추출했는지 여부에 대한 리트머스 테스트는 코드베이스가 자격 증명을 손상시키지 않고 쉽게 오픈 소스화될 수 있는지 여부입니다."어딘가에, 구성을 코드 베이스에 넣을 수 없습니다. "또 다른 구성 방법은 버전 관리에 체크인되지 않은 구성 파일을 사용하는 것입니다."

Twelve Factor Apps에서는 "실수로 구성 파일을 저장소에 체크인하기 쉽습니다."라고 말합니다. 이 문제를 해결하려면 프로덕션 구성(예: 개인 키)이 개발 및 테스트 구성과 달라야 합니다. 그들도 그래야 한다엄격하게통제. 일부 버전 제어 시스템에는 특정 파일이 체크인되지 않도록 차단하는 git블랙리스트(예: 파일)가 있습니다 . .gitignore이것들도 사용해야 합니다. "구성 파일은 다양한 위치와 다양한 형식으로 흩어져 있는 경향이 있으므로 한 곳에서 모든 구성을 보고 관리하기가 어렵습니다. 또한 이러한 형식은 언어 또는 프레임워크에 따라 달라지는 경향이 있습니다. "구성 파일에서 정의하기만 하면 됩니다." 환경 변수"를 사용하면 이 문제를 해결할 수 있습니다. 그런 다음 서버는 시작 시 이를 환경에 로드할 수 있습니다.

나는 무엇을 할 것인가:

  1. 프로덕션 서버 구성 정보(예: 서버의 개인 키)를 기본 저장소와는 별개의 별도 저장소에 저장합니다.
  2. 프로덕션 구성 파일을 잘 보호하십시오. 팀의 모든 개발자가 아닌 소수의 사람만 액세스하면 됩니다. 예를 들어 QA/DevOps/시스템 관리자/등입니다. 이 파일은 아마도 거기에 있을 것이므로 서버의 키라고 생각하십시오. 개발 및 테스트 환경에는 프로덕션 환경과 다른 자격 증명 및 키가 있어야 합니다. 그런 다음 더 느슨하게 저장할 수 있습니다.
  3. 서버의 init 루틴이 구성 파일 정보를 실제 환경 변수에 로드하도록 합니다.
  4. 애플리케이션이 런타임 시 환경 변수에서 필요한 구성 정보를 로드하도록 허용

관련 정보