공유 CA, 별도의 문: 허용 파일당 하나의 서비스

공유 기관에 대해 검증되는 인증서는 신뢰의 시험을 통과한 것이지 구성원 자격의 시험을 통과한 것이 아닙니다. 이 두 결정은 둘 다 연결 시점에 일어나기 때문에 자주 뒤섞이며, 그 뒤섞임은 서비스에 있어서는 안 될 사람이 그곳에 허용될 때까지 보이지 않습니다. 해결책은 두 번째 기관이 아니라, 서비스마다 내려지고 데몬이 읽는 곳에 기록되는 두 번째 결정입니다. 두 가지를 분리해 두면 이 영역의 혼란 대부분이 사라집니다.

신뢰 체인은 서비스 구성원 자격에 대해 아무것도 말하지 않습니다

두 서비스가 같은 발급 계층을 받아들이면서도 서로 다른 사용자 집단을 가질 수 있습니다. 한 노트북은 첫 번째에 속하며 두 번째에 도달해서는 안 되지만, 같은 계층의 다른 클라이언트는 실제로 그곳에 속합니다. 그 서비스에서 기관을 제거하면 정당하게 사용하는 모든 사람이 잠기게 되므로, 작업은 신뢰가 아니라 허용입니다.

하나의 문에 두 개의 자물쇠를 상상하면 도움이 됩니다. 인증서가 바깥 자물쇠를 열고, 서비스별 결정이 안쪽 자물쇠를 엽니다; 어느 것도 다른 것을 대신하지 않습니다. 바깥 자물쇠만 있는 서비스는 구성원 자격을 전혀 강제하지 않으며 단지 인증만 합니다. 작동하는 연결의 형태로만 존재하는 정책은 감사할 수 없기 때문에, 무엇이든 바꾸기 전에 두 결정을 모두 적어 두십시오. 다음 내용은 안쪽 자물쇠에 관한 것입니다.

선택적 재정의를 허용 관문으로 바꾸십시오

클라이언트 구성 디렉터리는 보통 편의 기능으로, 그 안의 파일은 이름을 지정한 클라이언트의 설정을 재정의하고 파일이 없는 클라이언트는 서버 기본값으로 실행됩니다. 하나의 지시문이 그 편의를 관문으로 바꾸어, 파일이 없으면 연결이 거부되게 합니다.

client-config-dir /etc/openvpn/service-a/clients
ccd-exclusive

커뮤니티 버전 OpenVPN 2.6 ccd-exclusive은 매뉴얼 페이지에서 바로 이 조건을 문서화하며, 이름이 지정된 파일 조회는 클라이언트의 실제 신원에 기반합니다. 다른 빌드와 제품이 관리하는 서버는 다를 수 있으므로, 다른 곳에서 같은 의미론에 의존하기 전에 설치된 버전을 확인하십시오.

위 경로를 예로 보고, 안내서가 지어낸 디렉터리를 만드는 대신 실제 배포된 배치를 확인하십시오. 이 조각은 조건을 추가할 뿐 아무것도 제거하지 않으므로, 기존 인증서 검사, 서버 신원 검사, 계정 인증은 그대로 두십시오. 잘못된 지점에서 발생한 거부는 인증서 장애처럼 보여 조사를 기관으로 보내므로, 변경은 운영 전에 준비하십시오. 그런 다음 거부된 클라이언트의 로그 줄이 체인이 아니라 누락된 구성 파일을 지목하는지 확인하십시오.

서비스마다 하나의 디렉터리, 하나의 공유 목록이 아닙니다

구성원 자격은 그것을 강제하는 서비스에 속하므로, 각 서비스는 자신의 디렉터리와 자신의 파일을 유지합니다. 두 서비스를 하나의 목록으로 향하게 하면 구성원 자격을 공유하게 됩니다 누군가 의도했든 아니든, 그리고 그 결과 바뀐 내용을 결정까지 추적하기 어렵습니다. 공유 기관은 공유로 남을 수 있지만 허용 파일은 그럴 수 없습니다. 이들을 분리해 두면 한 서비스의 실수가 다른 서비스를 조용히 넓힐 수 없습니다.

DEFAULT 항목은 사람들을 오도하는 경우입니다. 이름이 지정된 파일이 없을 때 대체 설정을 제공하지만, 관문이 요구하는 이름이 지정된 파일은 아니므로 단독으로 클라이언트를 허용할 수 없습니다. 항목이 전혀 없는 클라이언트를 시험해 거부를 확인하십시오; 그 클라이언트가 허용된다면 대체가 적용되고 있으며 ccd-exclusive 그 인스턴스에서는 유효하지 않습니다.

실제 신원이 어느 파일을 읽을지 결정합니다

조회는 클라이언트가 실제로 인증한 신원을 사용하며, 보통 인증서의 공통 이름입니다. 서버가 사용자 이름과 암호도 검증하고 그 이름을 공통 이름에 매핑하면, 파일은 대신 인증된 사용자 이름과 일치해야 합니다. 불일치는 결코 선택되지 않는 그럴듯한 파일 이름으로 디렉터리를 가득 채웁니다.

읽기는 나머지 절반입니다. 데몬은 보통 시작 후 권한을 버리므로, 축소된 계정은 디렉터리와 그 안의 모든 항목에 대한 읽기 권한이 필요합니다. 셀프서비스 허용은 메커니즘을 완전히 무력화하므로, 클라이언트가 쓰기 가능한 경로로 자신의 항목을 만들 수 있어서는 안 됩니다. 한 계정에 닫힌 것처럼 보이는 디렉터리가 다른 계정에는 열려 있을 수 있으므로, 파일 모드만이 아니라 마운트와 공유 권한도 확인하십시오. 그런 다음 unit 파일이 언급하는 계정이 아니라, 실행 중인 프로세스가 실제로 어느 계정을 사용하는지 확인하십시오. 둘은 다른 무엇도 바꾸지 않았을 때만 같습니다.

거부, 허용, 폐기를 각각 따로 관찰하십시오

서비스에 속한 신원을 시험해 연결되는지 확인하십시오. 항목이 없는 유효한 인증서를 시험해 거부되는지 확인하십시오. 다른 서비스에 허용된 신원을 시험해 여기서는 허용되지 않는지 확인하십시오. 그 맥락이 없으면 아무도 결과를 재현할 수 없으므로, 각 결과 옆에 서비스 인스턴스와 실제 신원을 기록하십시오.

회수는 폐기와 별개의 작업입니다. 허용 파일을 편집하면 한 서비스의 권한이 제거되지만 신원은 다른 모든 곳에서 유효하게 남는 반면, 손상된 키는 조직의 폐기 대응이 필요합니다. 디렉터리 편집도 폐기 목록도 그 세션을 스스로 끝내지 않으므로, 이미 설정된 세션을 어떻게 할지 미리 결정하십시오.

허용은 첫 번째 관문일 뿐입니다. 서비스에 참여한다고 해서 그 뒤의 서브넷, 데이터베이스, 관리 인터페이스에 대해 알 수 있는 것은 아니며, 그 리소스 정책은 따로 작성하고 시험해야 합니다.