AnyConnect의 신뢰할 수 없는 서버 경고: 수락할까, 가져올까

AnyConnect에 게이트웨이 호스트 이름을 붙여 넣으면 창이 빨간색이나 흰색으로 바뀌고, 클라이언트가 인증서를 확인할 수 없는 서버를 신뢰할지 묻는 대화 상자가 뜹니다. 자연스러운 행동은 그냥 클릭하고 작업을 계속하는 것이지만, 그것이 바로 잘못된 반사입니다. 답은 해당 단말의 클라이언트 환경 설정에 기록되고 이후 연결에도 적용되므로, 이 대화 상자는 일회성 경고의 옷을 입은 구성 결정입니다. 클라이언트가 보여 주는 순서대로 제가 밟는 절차입니다.

실제로 보이는 경고부터 시작하십시오

빨간색과 흰색은 겉모양의 차이가 아닙니다. 빨간색 경고는 프로필이나 환경 설정이 신뢰할 수 없는 서버를 차단하도록 되어 있다는 뜻이므로, 그 설정이 바뀌기 전까지 클라이언트는 진행을 거부합니다. 흰색 경고는 분명하게 답하면 진행을 허용한다는 뜻입니다. 비슷해 보이지만 다르게 동작하는 세 번째 경우가 있습니다. 만료된 인증서인데, 가져와도 유효해지지 않기 때문에 클라이언트는 가져오기를 아예 제안하지 않습니다. 이 셋을 구분하는 데 일 초면 충분하고, 그 뒤의 모든 것이 여기서 결정됩니다.

그 모두의 뒤에는 짧은 원인 목록이 있습니다. 자체 서명된 게이트웨이 인증서, 엔드포인트가 신뢰하지 않는 사설 CA, 또는 인증서의 subject alternative names에 없는 호스트 이름입니다. 셋 중 어느 것이든 같은 대화 상자를 띄우고 서로 다른 해결책을 요구합니다.

대화 상자에 답하기 전에 인증서를 읽으십시오

경고에서 인증서 세부 정보를 열고 버튼을 누르기 전에 세 항목을 보십시오. subject와 SAN은 실제로 도달하려던 게이트웨이를 가리켜야 하고, 발급자는 조직이 운영하는 CA여야 하며, 유효 기간은 오늘을 포함해야 합니다. 그다음 SHA-256 지문을 이 연결이 아닌 다른 곳에서 얻은 사본, 사내 문서 페이지나 티켓과 비교하십시오. 같은 대화 상자에서 읽은 지문은 아무것도 증명하지 못합니다. 독립적인 사본을 찾지 못한다면 그 예외를 받아들일 근거가 없습니다.

실험실과 운영 게이트웨이를 가르는 단계가 이것입니다. 어제 만든 자체 서명 인증서가 있는 시험 장비라면 클릭해서 넘어가는 것이 합리적입니다. 사용자가 이어서 자격 증명을 입력하는 기업 게이트웨이라면, 확인할 수 없는 인증서는 그럴듯한 가로채기 구성이며, 아직 그 질문을 던지는 유일한 구성 요소는 클라이언트입니다.

각 답이 신뢰 저장소에 무엇을 쓰는지 아십시오

가져오기 질문에 예라고 답하면 해당 단말의 클라이언트 신뢰 저장소에 게이트웨이 인증서가 추가됩니다. 세션별 예외가 아닙니다. 이후 연결은 같은 질문 없이 완료될 수 있으며, 그것이 목적이자 위험입니다. 화면 어디에도 그 예외가 존재한다는 것을 알려 주지 않기 때문입니다. 아니오라고 답하면 이 세션에 대해서만 로그인이 이어집니다. 두 경로 모두 연결되지만, 단말을 바꾸는 것은 하나뿐입니다.

빨간색 경로에 있다면 첫 시도는 로그인이 아닙니다. 문서화된 입력 순서는 connect 줄과 두 번의 확인이며, 이는 환경 설정을 바꾸고 종료합니다. 이것을 성공으로 처리하는 스크립트는 설정만 저장했을 뿐 인증은 하지 않은 것입니다. 인증서 가져오기 질문은 다음 시도에서야 나타나므로, 사람들은 이 질문이 간헐적이라고 결론짓습니다.

그 순서는 손가락뿐 아니라 자동화에도 중요합니다. 항상 예라고 답하는 스크립트 응답은 게이트웨이가 바뀐 뒤에도 계속 동작하고, 다음에 나타나는 어떤 인증서든 계속 신뢰합니다.

클라이언트가 묻는 순서대로 답을 작성하십시오

클라이언트가 경고하지만 연결을 허용할 때, 답은 정해진 순서로 옵니다. connect, 계속하려면 예, 그다음 가져오기 질문, 그다음 그룹, 사용자 이름, 비밀번호입니다. 질문 시점을 추측하는 대신 입력 파일에 별도 줄로 적으십시오. 가져오기를 거부하는 것은 같은 파일에서 한 글자를 바꾸는 일이며, 감독 없이 실행되는 모든 것에 더 안전한 기본값입니다.

connect vpn2.example.net
y
n
GROUP
LOGIN
PASSWORD

모든 스크립트에 리프 인증서를 받아들이도록 가르치기보다 조직의 CA를 엔드포인트에 배포하는 편이 낫습니다. 올바른 SAN이 있는 제대로 발급된 인증서는 모두에게서 그 질문을 없애고, 검증의 의미를 유지하며, 한 엔드포인트의 결정 기억에 의존하지 않습니다. 루트 CA 설치는 리프를 가져오는 것보다 무거운 변경이므로, 헬프데스크의 지름길이 아니라 관리된 배포로 다루십시오.

게이트웨이보다 오래 사는 예외를 제거하십시오

AnyConnect는 이 환경 설정을 단말별로 저장하므로, 사무실을 옮긴 노트북에는 오래된 답이 쌓입니다. 관리되는 엔드포인트에서 저장된 환경 설정과 가져온 인증서를 검토하고, 소유자가 바뀐 호스트 이름을 예외가 아직 가리키는지 확인하십시오. 신뢰할 수 없는 서버를 무엇이든 받아들이는 설정은 그것이 만들어진 인증서보다 넓은 범위를 가집니다.

지킬 가치가 있는 패턴은 좁습니다. 정상 사용을 위한 신뢰된 인증서, 일시적 예외를 위한 문서화된 대역 외 지문 확인, 그리고 이전이 끝나면 그것을 제거하는 이름 있는 담당자입니다. 관리하는 단말에서 어떤 서버든 받아들이는 포괄 설정을 찾는다면, 편의가 아니라 발견으로 취급하십시오.