FortiGate VPN MFA: 로컬 토큰, RADIUS, SAML 중 무엇을 쓸까

게이트웨이, RADIUS 백엔드, SAML 공급자가 각각 인증 요소를 검증할 수 있으며 실패 방식도 다릅니다. 서비스, 클라이언트, 복구 경로를 함께 맞추십시오.

모든 FortiGate VPN MFA 설계는 먼저 두 번째 요소를 누가 검증하는가라는 한 가지 질문에 답합니다. 게이트웨이가 로컬 토큰이나 이메일로 보낸 코드로 직접 검증할 수도 있고, RADIUS 백엔드가 이를 강제하고 챌린지를 돌려줄 수도 있으며, SAML ID 공급자가 브라우저에서 전체 절차를 맡을 수도 있습니다. 각 방식은 로그인 순서와 실패 징후, 복구 절차가 모두 다르며, 명령 블록을 서로 복사하면 그럴듯해 보이지만 아무도 인증하지 못하는 구성이 됩니다. 이 글은 각 설계가 로그인 중에 실제로 무엇을 하는지, 어디서 깨지는지를 설명합니다.

로그인 절차가 요소의 소유자를 결정한다

처음 두 설계에서 FortiGate는 신뢰하는 쪽입니다. 자격 증명을 수집하고, 두 번째 요소가 필요한지 판단하며, 로컬에서 또는 챌린지를 통해 검증합니다. 세 번째 설계에서 게이트웨이는 검증자가 아니라 중계자가 되어 클라이언트를 ID 공급자로 리디렉션하고, 어서션을 받아, 주장된 신원을 사용자와 그룹에 매핑합니다. RADIUS 설계에서는 그 중간에 위치하여 정책을 가진 백엔드와 요청-응답 교환을 수행합니다.

이 차이가 어떤 증거를 모을 수 있는지를 결정합니다. 게이트웨이가 검증하면 자체 디버그 출력이 무슨 일이 있었는지 알려줍니다. ID 공급자가 검증하면 게이트웨이는 어서션이 도착했다는 것만 알며, «MFA가 실제로 요구되었는가»의 답은 공급자의 로그에 있고 방화벽 로그에는 없습니다. 잘못된 로그를 읽는 것은 설계대로 동작하는 배포를 잘못 진단하는 가장 흔한 방식이며, 서비스 자체도 절차를 제한합니다. FortiOS 7.6.3은 SSL VPN 터널 모드를 제거하고 IPsec을 채택하지만, 웹 모드는 지원 모델에서 Agentless VPN으로 계속되므로, 한 서비스에서 입증된 절차가 다른 서비스에서 자동으로 제공되지는 않습니다.

로컬 검증: 토큰과 이메일 코드

FortiGate가 관리하는 요소는 사용자 객체에 연결되며, FortiToken이나 문서화된 토큰 통합에는 등록, 지원되는 검증 절차, 해당되는 경우 라이선스, 교체 절차가 필요합니다. 이메일 코드에는 동작하는 SMTP 경로와, 터널이 생기기 전에 사용자가 접근할 수 있는 사서함이 필요합니다. 이는 암호학과는 무관하고 누군가 로그인할 수 있는지와 전적으로 관련된 의존성입니다.

config user local
    edit "jdoe"
        set type password
        set two-factor fortitoken
        set fortitoken FTKMOB1234567890
    next
end

이메일 전달은 인증 가용성의 일부이며, VPN으로만 접근할 수 있는 사서함은 누구에게도 스스로 해결되지 않는 순환을 만듭니다. 전달 지연, 코드 유효 기간, 원격 인증 시간 제한은 세 가지 별개의 제약입니다. 하나를 늘려도 접근 불가능한 사서함이 고쳐지지 않으며, 순환을 시험해 본 적 없는 설계는 휴가 후 첫 비밀번호 재설정에서 이를 발견합니다.

보증 요구 사항도 여기에 속하므로 제품 선택 전에 확인하십시오. NIST SP 800-63B는 이메일을 대역 외 인증에 허용할 수 없는 수단으로 보며, 따라서 준수를 주장하는 배포는 아무리 편리하더라도 이메일 코드를 두 번째 요소로 쓸 수 없습니다. 장비에 기능이 있다는 것이 그 기능이 특정 표준을 충족한다는 진술은 아닙니다.

RADIUS: 게이트웨이가 묻고 백엔드가 결정한다

RADIUS에서는 FortiGate가 자격 증명을 요소 정책을 가진 백엔드로 보내며, 교환은 단순한 수락이나 거부일 수도 있고, 클라이언트가 답해야 하는 챌린지를 포함할 수도 있습니다. 그 경우 VPN 서비스와 클라이언트 모두 그 챌린지 형태를 지원해야 합니다. 푸시 승인을 강제하는 백엔드와 비밀번호에 여섯 자리 코드를 붙이는 것만 아는 클라이언트는 중간에서 만나지 못합니다.

config user radius
    edit "corp-radius"
        set server "10.10.20.15"
        set secret ENCXXXXXXXX
        set secondary-server "10.10.20.16"
    next
end
diagnose test authserver radius corp-radius pap jdoe <password>

터널을 탓하기 전에 백엔드를 따로 시험하십시오. authserver 시험이 성공하는데 VPN 로그인이 실패한다면 차이는 자격 증명이 아니라 챌린지 처리에 있으며, 게이트웨이 인증 데몬의 디버그가 그것이 드러나는 곳입니다:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: 브라우저가 게이트웨이를 떠난다

SAML 설계에서 클라이언트는 ID 공급자로 리디렉션되어 그곳에서 인증하고, 게이트웨이가 신뢰 관계와 그룹 매핑에 대해 검증하는 어서션을 가지고 돌아옵니다. 게이트웨이는 비밀번호도 두 번째 요소도 보지 않으며, 실패가 이제 방화벽이 들여다볼 수 없는 브라우저 세션에서 일어나기 때문에 이는 보안 개선이자 동시에 운영상의 복잡함입니다.

어서션을 받아들인다고 해서 공급자가 그 로그인에 MFA를 요구했다는 것이 증명되지는 않습니다. 일부 애플리케이션에만 MFA를 적용하는 공급자 정책은 요청한 그대로의 로그인을 제공하면서 가정한 보증은 전혀 주지 않습니다. 이 특정 애플리케이션에 대한 공급자 정책을 확인하고, 어느 쪽에서 이름을 바꾼 뒤에도 그룹 클레임의 FortiGate 그룹 매핑이 여전히 일치하는지 확인하십시오.

클라이언트 지원은 여기서 어디보다 중요합니다. 일부 VPN 클라이언트는 브라우저 인계를 기본으로 처리하고, 일부는 시스템 브라우저를 열며, 헤드리스나 명령줄 클라이언트는 흐름을 아예 완료하지 못할 수 있습니다. 프로필을 게시하기 전에 사용자가 실제로 실행하는 클라이언트와 실제로 쓰는 플랫폼에서 시험하십시오.

복구도 메커니즘의 일부다

위의 모든 설계에는 접근 불가능한 사서함, 분실한 토큰, 챌린지를 거부하는 백엔드, 잠긴 ID 공급자 계정처럼 한 번에 한 사용자에게 실패할 수 있는 의존성이 있습니다. 누가 접근을 복구할 수 있는지, 어떤 지원 절차로, 요청하는 사람을 어떻게 확인하고 진행할지를 지금 정하십시오. VPN 경로와 분리해 두는 비상 로컬 관리자 계정은 하나의 통제입니다설명 없는 비밀번호만의 우회는 발견을 기다리는 사고입니다.

그다음 배포 전에 정상 로그인, 거부되었거나 만료된 요소, 승인된 분실 인증기 복구라는 세 가지 로그인을 시험하십시오. 각각이 어느 로그에 나타나는지 기록하십시오. 그 기록이 «MFA가 켜져 있다»를 다른 사람이 운영할 수 있는 설계로 바꿉니다.

관련 글