SSO 감사 로그, 무엇을 얼마나 오래 보관해야 할까?
SSO·MFA·계정 변경 기록의 보존 범위를 정하고, 개인정보 노출과 감사 대응 사이의 균형을 잡는 실무 기준을 소개합니다.
보안 사고나 고객사의 보안 심사가 시작되면 가장 먼저 나오는 질문 중 하나는 “누가, 언제, 어떤 계정으로, 무엇을 변경했는가”입니다. SSO를 도입했더라도 로그인 성공 기록만 남긴다면 계정 탈취, 권한 오남용, 퇴사자 접근의 흐름을 재구성하기 어렵습니다.
최근 보안 규제와 사이버 감사에서는 단순한 로그 수집보다 접근 통제의 근거를 설명할 수 있는 추적 가능성이 강조됩니다. 그러나 모든 데이터를 무기한 쌓는 것도 정답은 아닙니다. 로그는 사고의 블랙박스인 동시에 사용자 정보가 모이는 저장소이기 때문입니다.
먼저 보존 목적을 나누세요
사고 조사에 필요한 인증 기록
로그인 성공·실패, MFA 등록·재설정·실패, 세션 종료, 비상 계정 사용은 계정 탈취 여부를 판단하는 핵심 기록입니다. 시각은 UTC로 일관되게 저장하고, 조회 화면에서 사용자 시간대로 표시하면 여러 지역의 사건을 비교하기 쉽습니다. SSO 사고 시 확인 순서는 SSO 사고 대응과 감사 로그에서 살펴볼 수 있습니다.
권한 변경을 설명하는 관리 기록
사용자 초대·비활성화, 그룹 변경, 앱 할당, SCIM 동기화, OIDC·SAML 앱 설정 변경에는 실행자와 대상, 변경 시각, 결과를 남겨야 합니다. 변경 전후 값이 필요하더라도 클라이언트 시크릿, SCIM 토큰, TOTP 시드 같은 비밀값은 기록하지 않습니다.
보존 기간은 하나의 숫자가 아닙니다
법률과 인증 기준, 고객 계약, 사고 조사에 필요한 기간은 조직마다 다릅니다. 따라서 “모든 로그 1년”처럼 일괄 적용하기보다 다음 세 기준으로 정책을 만드세요.
• 적용되는 법률·인증·고객 계약의 최소 요구 기간
• 위협 탐지와 사고 조사의 현실적인 조회 범위
• 개인정보 최소 수집, 저장 비용, 삭제 요청에 대한 영향
예를 들어 최근 기록은 빠르게 검색할 수 있는 저장소에 두고, 오래된 기록은 접근 권한이 제한된 보관 영역으로 옮길 수 있습니다. 기간이 끝나면 자동 삭제하고, 법적 보존이 필요한 사건만 승인 절차를 거쳐 예외로 유지합니다.
로그 자체도 보호 대상입니다
감사 로그를 수정하거나 삭제할 수 있는 권한은 일반 관리자 권한과 분리하고, 조회와 내보내기 역시 기록해야 합니다. 테넌트별 데이터가 섞이지 않도록 격리하고, CSV·PDF 내보내기에는 기간과 대상 범위를 명시하세요. 정기 점검 항목은 ISMS-P 계정 감사 자료 준비와 SaaS 접근 권한 정기 검토를 함께 참고하면 좋습니다.
AxiPass로 인증부터 감사 대응까지 연결하세요
AxiPass는 SaaS 기업용 멀티 테넌트 IdP로 OIDC·SAML SSO, SCIM, MFA, SWA와 감사 로그를 통합합니다. 고객사별 테넌트를 분리하고 로그인, 계정 수명주기, 앱 접근 변경을 한 흐름에서 추적해 보세요. 보존 정책은 조직의 법률·계약 요건을 검토해 별도로 확정해야 합니다.