SAML은 왜 이렇게 복잡할까: 기업 로그인의 보안과 호환성 딜레마

핵심 요약

• SAML은 회사의 인증 시스템이 확인한 사용자 정보를 다른 서비스에 전달하는 표준입니다.
• 전자서명이 유효해도 로그인에 필요한 검증이 모두 끝난 것은 아닙니다.
• 서명으로 검증한 데이터와 서비스가 실제로 사용하는 데이터가 다르면 보안 문제가 생길 수 있습니다.
• 다양한 연동 방식을 지원할수록 허용할 메시지와 거부할 메시지를 명확하게 구분해야 합니다.

회사 계정 하나로 협업 도구와 인사 시스템에 들어가는 일은 익숙합니다. 로그인 버튼을 한 번 누르면, 그 뒤에서는 서로 다른 시스템이 “이 사용자를 믿어도 되는가”를 판단합니다. 이 시스템들을 연결하는 SAML을 살펴보면 기업 로그인이 편리한 만큼 구현하기는 까다로운 이유를 알 수 있습니다.

SAML은 비밀번호 대신 ‘인증 확인서’를 전달합니다

SAML은 Security Assertion Markup Language의 약자입니다. 이름은 길지만 기업의 통합 로그인인 SSO에서 하는 일은 비교적 단순합니다.

직원이 업무용 서비스에 접속하면 회사의 인증 시스템이 신원을 확인합니다. 이 시스템을 IdP, 즉 신원 제공자라고 부릅니다. 업무용 서비스는 SP, 즉 서비스 제공자입니다.

IdP는 인증 결과를 담은 메시지를 SP에 전달합니다. 메시지에서 사용자와 인증 결과 등에 관한 주장을 담은 부분을 ‘어설션’이라고 합니다. 쉽게 말하면 “이 사용자를 이렇게 인증했습니다”라는 확인서입니다.

덕분에 업무용 서비스마다 회사 비밀번호를 직접 받아 검사할 필요가 줄어듭니다. 대신 서비스가 확인해야 할 것이 있습니다. 전달받은 확인서를 믿어도 되는지 정확히 판단해야 합니다.

서명이 맞다는 것과 로그인해도 된다는 것은 다릅니다

SAML 메시지는 XML이라는 문서 형식을 사용합니다. 여기에 전자서명을 붙여 특정 데이터의 무결성과 서명 주체를 확인할 수 있습니다.

다만 서명 검증은 로그인을 허용할지 판단하는 여러 단계 중 하나입니다. 계산상 서명이 맞더라도, 서비스가 신뢰하도록 설정한 IdP의 키로 만든 서명인지 확인해야 합니다.

그다음에는 메시지에 담긴 내용이 로그인 조건에 맞는지 살펴야 합니다.

• 이 인증 결과가 우리 서비스를 대상으로 발급됐는지
• 허용된 유효 시간 안에 있는지
• 현재 로그인 흐름에 맞는 응답인지
• 이미 사용한 메시지를 다시 제출한 것은 아닌지

예를 들어 다른 서비스를 대상으로 발급된 인증 결과라면, 서명이 온전해도 우리 서비스의 로그인 근거로 받아들여서는 안 됩니다.

출입증에 진짜 직인이 찍혀 있다고 모든 건물에 들어갈 수는 없는 것과 같습니다. 믿을 만한 발급자가 발급했는지, 출입증의 사용 조건에 맞는지 함께 확인해야 합니다.

검증한 데이터와 사용한 데이터가 같아야 합니다

XML 문서 안에서도 문제가 생길 수 있습니다. XML 전자서명은 참조로 지정한 요소를 대상으로 검증할 수 있습니다. 따라서 “서명 검증에 성공했다”는 결과만 보고 문서 안의 다른 데이터까지 믿으면 위험합니다.

이 틈을 노리는 공격 유형이 XML 서명 래핑입니다. 이 공격은 서명을 위조하지 않고도 서명 검증 코드와 로그인 처리 코드가 서로 다른 요소를 보도록 만듭니다.

가령 검증 코드는 정상적으로 서명된 어설션을 확인했는데, 로그인 코드는 문서의 다른 위치에서 공격자가 통제하는 데이터를 읽는 식입니다. 이 경우 서명 자체는 유효해도 잘못된 사용자 정보로 로그인을 허용할 수 있습니다.

모든 SAML 제품에서 이 공격이 가능한 것은 아닙니다. 검증한 요소와 실제로 사용하는 요소를 제대로 연결하지 못한 구현에서 문제가 생깁니다.

“문서 어딘가에 유효한 서명이 있다”는 것만으로는 보안을 보장할 수 없습니다. 지금 로그인에 사용하는 바로 그 데이터가 검증됐는가를 확인해야 합니다.

호환성을 넓힐수록 검증할 조건도 늘어납니다

기업용 서비스는 여러 고객사의 인증 시스템과 연결돼야 합니다. 시스템마다 서명이 붙는 위치나 사용자를 식별하는 방식이 다를 수 있고, 전달하는 속성에도 차이가 있어 이를 처리해야 합니다.

이런 차이가 곧 취약점이라는 뜻은 아닙니다. 어려운 점은 지원하는 조합마다 보안 조건을 빠짐없이 적용해야 한다는 것입니다.

예를 들어 어떤 연동에서는 응답 전체의 서명을 처리하고, 다른 연동에서는 내부 어설션의 서명을 처리할 수 있습니다. 어느 쪽이든 실제로 사용하는 인증 정보를 신뢰할 수 있는 서명이 보호하는지 확인해야 합니다. “서명 하나가 통과했으니 나머지도 괜찮다”고 처리해서는 안 됩니다.

로그인을 시작하는 방식도 다릅니다. 서비스에서 로그인을 시작했다면 요청과 응답을 연결해 검사할 수 있습니다. 반면 IdP의 앱 목록에서 시작하는 로그인은 앞선 요청이 없으므로, 이런 흐름을 별도로 다뤄야 합니다.

검증 조건 하나를 살펴보면 그 안에서 확인할 조건이 다시 여럿 나옵니다. SAML의 복잡함을 프랙털에 빗댈 만합니다. XML이라는 형식도 까다롭지만, 문서 구조를 읽으면서 서명이 어디까지 적용되는지, 로그인 절차와 어떻게 맞물리는지 함께 정확하게 해석해야 해서 어렵습니다.

호환성을 위해 예외를 허용할 때도 조건을 구체적으로 정해야 합니다. 고객사별로 어떤 발급자와 키를 신뢰하고 어떤 형태의 메시지를 허용할지 명확해야 합니다. 연동을 성사시키려고 검증 조건을 느슨하게 만들면, 편의를 위한 기능이 공격에 쓰일 수 있습니다.

SAML이 편리한 이유는 여러 서비스가 인증 결과를 믿고 받아들일 수 있기 때문입니다. 그래서 어디까지 믿을지 범위를 좁고 정확하게 정해야 합니다. 회사의 SSO를 점검할 때도 로그인이 성공하는지 확인하는 데서 끝내지 말고, 받아들이면 안 되는 로그인까지 제대로 거부하는지 살펴야 합니다.