VPN 서버 이미지를 그 정체성은 복제하지 않고 복제하기

이미지가 부팅되고 서비스가 시작되며 클라이언트가 접속합니다. 바로 그때 멈춰서 두 가지 매우 다른 작업 중 무엇이 방금 일어났는지 물어야 합니다. 복사본이 이전에 존재하던 하나의 논리 게이트웨이를 복원하는지, 아니면 함대에 두 번째 게이트웨이를 추가하는지입니다. 둘 다 정당하며 정체성과 접근에 서로 다른 결과를 낳습니다. 깔끔하게 올라온다는 사실은 둘 중 어느 것도 증명하지 않습니다.

세 가지 조건이 답을 결정하며, 그것은 이미지가 담을 수 있는 세 가지 자재 바구니입니다. 이미지를 빌드하기 전에 분류하십시오. 두 번 배포한 뒤가 아니라.

먼저 두 작업 중 어느 것을 하고 있는지 결정하십시오

복원은 하나의 서비스 정체성을 유지합니다. 이전 인스턴스는 사라지고 이름과 인증서는 남으며, 클라이언트는 같은 엔드포인트를 계속 신뢰합니다. 추가는 두 번째 정체성을 만들며, 클라이언트와 로그와 폐기가 모두 이를 구분해야 합니다.

이 구분은 겉치레가 아닙니다. 두 라이브 호스트가 같은 게이트웨이 인증서를 제시하면 클라이언트는 둘을 구분할 수 없고 감사 추적도 구분할 수 없으며, 그 인증서를 폐기하면 둘이 동시에 사라집니다. 의도적인 고가용성 설계가 바라는 것이 정확히 그것일 수 있지만, 급하게 만든 이미지 복사본이 의도하는 것은 거의 아닙니다.

따라서 첫 결정은 한 문장이며, 이미지가 빌드 호스트를 떠나기 전에 적어야 합니다. 이 복사본은 게이트웨이 A를 복원한다, 또는 이 복사본은 게이트웨이 B가 된다. 그 뒤의 모든 것은 그 문장에 대한 회계입니다. 아무도 그것을 쓸 수 없다면 그 복사본은 빌드할 준비가 되지 않았습니다.

재사용 가능한 입력, 정체성과 권한, 배포 상태

재사용 바구니는 쉬운 쪽입니다. 패키지, 비밀이 없는 검토된 구성, 서비스 템플릿, 강화 설정. 이미지가 정말 잘하는 일이며 한없이 재현할 수 있습니다.

정체성과 권한 바구니가 바로 복사본이 잘못되는 곳입니다. 게이트웨이의 개인 키와 인증서는 모든 클라이언트에게 그 게이트웨이를 식별시킵니다. 인증 기관의 서명 키는 다른 힘을 지닌 다른 객체이며 정체성을 발급합니다. 발급자를 신뢰한다고 해서 모든 새 게이트웨이에 발급 능력이 필요한 것은 아니며, 서명 키를 이미지 안에 넣어 배포하면 이미지를 읽을 수 있는 모든 것에 그 능력을 부여하는 셈입니다.

배포 상태 바구니는 구성처럼 보여서 사람들이 잊는 쪽입니다. 수신 주소, 주소 풀, 푸시되는 경로, 리졸버 설정, 로컬 통합은 모두 첫 호스트에 대한 가정을 부호화합니다. 이를 복사한 두 번째 노드는 다른 게이트웨이가 이미 소유한 풀에서 할당하거나, 원본 옆에만 존재하는 자원으로 클라이언트를 보낼 수 있습니다.

새 노드에 무엇을 주어야 하는가, 누가 주는가

독립적으로 관리되는 노드는 승인된 등록 절차를 통해 자체 자격 증명을 받아야 하며, 서명 작업은 새 호스트가 아니라 서명 키가 있는 곳에서 이루어져야 합니다. 다른 노드를 방해하지 않고 회수할 수 있는 정체성이 무엇인지 기록하십시오. 답이 "전부"라면 그 설계는 하나의 정체성이 둘인 척하는 것입니다.

네트워크 값도 같은 대우를 받아야 합니다. 기존 게이트웨이와 충돌하지 않는 풀, 수신 주소, 푸시할 경로 집합을 골라 이미지가 아니라 프로비저닝 입력에 기록하십시오. 입력은 검토할 수 있지만 이미지는 그렇지 않습니다.

정당한 중간 사례가 있습니다. 지원되는 복구 또는 복제 설계는 이전 복사본에 대한 통제된 접근과 교체 계획을 갖추고 여러 호스트에 걸쳐 하나의 논리 서비스 정체성을 의도적으로 유지할 수 있습니다. 그것은 소유자가 있는 결정이며, 이미지가 편리했다는 이유로 생기는 기본값이 아닙니다.

openssl x509 -in /etc/openvpn/server/server.crt -noout -subject -issuer -dates
find /etc/openvpn -name '*.key' -o -name '*.pem' | head -20

첫 번째 명령은 노드가 실제로 어떤 정체성을 제시하고 누가 서명했는지 알려줍니다. 두 번째는 출발점 목록이며 증거가 아닙니다. 개인 자료는 그 디렉터리 밖에, 애플리케이션 데이터베이스 안에, 또는 실행 중인 파일 시스템이 더 이상 보여주지 않는 스냅샷 계층에 있을 수 있습니다.

이미지의 복사본이 조용히 지니는 것

이미지의 최신 리비전에서 파일을 삭제해도 이전 리비전, 계층 캐시, 또는 그것이 존재하던 동안 찍힌 스냅샷에서는 사라지지 않습니다. 그래서 자격 증명을 담은 이미지는 빌드되는 순간만이 아니라 수명 전체에 걸쳐 민감한 객체로 다루어야 합니다.

이미지 내용과 프로비저닝 입력을 별개의 질문으로 확인하십시오. 이미지는 "이 산출물 안에 무엇이 있는가"에 답하고, 입력은 "이 인스턴스가 첫 부팅에서 무엇이 되는가"에 답합니다. 공유 키를 가져오는 부트스트랩 스크립트가 있는 깨끗한 이미지는 첫 질문에는 잘, 둘째 질문에는 나쁘게 답합니다.

정당하게 비밀을 담은 복구 이미지는 필요한 사람으로 제한하고 어디에 보관되는지 기록하십시오. 대안인, 어떤 프로비저닝 없이도 동작해서 편리한 이미지는 그것을 발견한 누구에게나 게이트웨이의 정체성을 주는 같은 이미지입니다. 그 두 작업 중 빌드 로그에 나타나는 것은 하나뿐입니다.

프로덕션 전 승인 점검

노드가 트래픽을 받기 전에 네 가지를 확인하십시오. 제시하는 정체성, 받아들일 클라이언트, 접근이 허용된 자원, 그리고 배포하는 주소의 반환 경로.

systemctl status openvpn-server@lab --no-pager
ss -lunp 'sport = :1194'
ip -4 route show table all | grep -F '10.90.'

그다음 사고를 잡아내는 부정적 사례를 확인하십시오. 새 노드에 원본을 위해 마련된 관리자 또는 클라이언트 접근이 남아 있지 않은가. 복사된 구성은 추가 클라이언트 항목, 상속된 관리 경로, 또는 첫 호스트에서는 의미가 있던 푸시 지시문을 지닐 수 있습니다.

살아 있는 비밀을 담은 이미지가 이미 승인된 경계를 넘었다면 자격 증명을 교체하고 복사본을 격리하십시오. 최신 빌드에서 파일을 지우는 것은 이전 복사본이 여전히 지닌 자격 증명을 폐기하는 것과 같지 않으며, 그 두 사실 사이의 간격이 바로 공격자에게 필요한 창입니다.