MFA 서비스 중단: VPN 접속 허용을 미리 결정하세요

VPN 접속이 멈추고 경보는 두 번째 요소 서비스에 연결할 수 없다고 알립니다. 누군가 여전히 접속할 수 있는지는 장애 전에 답했어야 할 정책 질문이며, 장애 중에 정할 일이 아닙니다. 검증 서비스를 쓸 수 없다는 것은 요소가 통과했다는 증거가 아니며, 거부된 인증 요청은 연결 불가와 같은 사건이 아닙니다. 아래 런북은 그 구분을 시험할 수 있는 문서화된 규칙으로 바꿉니다.

1단계: 세 가지 결과를 따로 이름 붙이기

세 가지 상태를 적고 그것을 하나로 합치기를 거부하세요. 기본 인증 실패, 두 번째 요소 요청이 거부되거나 시간 초과된 상태, MFA 서비스가 전혀 응답하지 않은 상태로, 각각 담당자도 로그 줄도 올바른 대응도 다릅니다. 일반적인 시간 초과 메시지 하나는 어느 상태인지 감추고, 그 모호함이 장애를 논쟁으로 바꿉니다. 필요해지기 전에 런북에서 상태에 이름을 붙이세요.

거부는 검증 서비스가 응답해 아니라고 말한 것이며, 이는 가용성 문제가 아니라 정책의 결과입니다. 만료된 시도는 요청이 있었지만 아무도 제때 완료하지 못했다는 뜻입니다. 연결할 수 없는 서비스는 질문에 답이 전혀 오지 않았다는 뜻입니다. 세 번째만이 장애입니다.

2단계: 프록시가 실제로 쓰는 실패 모드 읽기

서비스에 연결할 수 없을 때 동작을 결정하는 설정을 찾아 템플릿이 아니라 실행 중인 구성에서 읽으세요. Duo의 RADIUS 프록시에서 문서화된 failmode 값은 safe과 secure이며, safe는 기본 인증이 성공할 때만 시도를 허용하고 secure는 그 조건에서 시도를 거부합니다.

radtest alice '' 127.0.0.1 0 testing123
journalctl -u duo-authproxy -n 50 --no-pager

safe라는 이름은 가용성 선택을 뜻하며, 허용된 모든 세션이 새로운 두 번째 요소를 가졌다는 보장이 아닙니다. 설정이 하는 거래가 바로 그것이므로 그 문장은 위험 등록부에 들어가야 합니다. 값을 다른 공급자, 다른 통합, 다른 프록시 모드로 일반화하지 말고 그 제품 자체의 대응 설정은 그 제품 문서를 읽으세요. 이 이해 없이 공급자 예제에서 복사한 구성은 다음 장애를 기다리는 놀라움입니다.

어느 모드가 활성인지 아무도 말할 수 없다면 멈추세요. 런북의 나머지는 그 답에 달려 있습니다.

3단계: 재시도를 흐름에 맞추기

게이트웨이의 시간 초과와 재시도 동작을 그것이 구동하는 인증 흐름에 맞추세요. 조정되지 않은 재시도는 여러 프롬프트를 만들고, 시도 대응을 혼란스럽게 하며, 로그가 어느 결과가 어느 로그인에 속하는지 말할 수 없게 만듭니다. 아주 긴 시간 초과는 가용성 설계가 아니라 같은 답을 더 오래 기다리는 것입니다.

ss -lunp 'sport = :1812'
tail -n 50 /var/log/duo/authproxy.log

프록시 자체의 요청 시간 초과는 별개의 한계로, 발행되었지만 끝나지 않은 인증 요청은 거부되며 그 거부는 되돌아갈 수 있는 장애가 아닙니다. 거부, 미완료 요청, 연결할 수 없는 서비스를 결정 표의 세 가지 다른 입력으로 다루세요. 그런 다음 어느 상태가 허용하고, 어느 상태가 붙잡고, 어느 상태가 사람에게 에스컬레이션되는지 표에 명시하세요.

두 구성 요소가 모두 재시도한다면 먼저 재시도의 소유권을 고치세요. 중복 프롬프트는 소유자가 둘 중 하나라는 증상이지 느린 서비스의 증상이 아닙니다.

4단계: 비상 접속을 따로 관리하기

비상 접속이 필요하다면 그 자체의 범위, 신원, 권한, 감사 추적을 주세요. 모든 사용자에게 MFA를 조용히 끄는 것은 비상 절차가 아니라 사고가 붙은 영구적 약화입니다. 보안 책임자가 허용 규칙, 가시성, 에스컬레이션 경로를 미리 승인합니다.

grep -R failmode /etc/duo /etc/radiusclient 2>/dev/null
systemctl status duo-authproxy

비운영 환경에서 기본 인증 실패, 의도적 거부, 요청 만료, 서비스 이용 불가라는 전체 매트릭스를 시험하세요. 각각에 대해 허용 결과와 기록된 이유를 남기세요. 구성된 동작을 알아내기 위해 운영 장애를 만들지 말고 비상 경로를 그 경로를 위해 쓰인 사고 도중에 처음 시험하지 마세요. 한 번도 실행되지 않은 복구 절차는 문서이지 통제가 아닙니다.

세 상태에 이름이 붙고, 실패 모드가 실행 중인 시스템에서 읽히고, 재시도에 소유자가 하나 있고, 비상 접속에 자체 승인과 검토가 있을 때 런북은 끝납니다. 예측 가능한 적용과 알려진 복구 경로가 문서화할 가치가 있는 결과입니다.