직원이 퇴사해서 관리자가 계정을 비활성화했습니다. 그런데 그 직원이 어제 열어 둔 노트북의 관리자 화면은 아직 동작합니다. 계정 상태를 바꾸는 것과 이미 발급된 세션을 끊는 것은 별개일 수 있기 때문입니다. 보안 사고 대응에서 ‘로그아웃시켰다’는 말은 브라우저 쿠키를 지웠다는 뜻이 아니라 이전에 발급된 인증 수단으로 서버가 더는 민감한 요청을 받아들이지 않는다는 뜻이어야 합니다.
현재 세션과 모든 세션을 구분한다
사용자가 직접 로그아웃하면 보통 지금 사용 중인 기기의 세션을 종료합니다. 비밀번호 유출이 의심되거나 퇴사·기기 분실이 발생했다면 모든 기기의 세션을 종료해야 합니다. 관리 화면에는 두 동작을 구분해 보여 주고, 다른 기기에서 누가 언제 로그인했는지 확인할 수 있게 합니다. 단순히 브라우저 쿠키의 만료일을 과거로 돌리면 지금 브라우저에서는 사라지지만, 복사된 쿠키나 다른 기기에 남은 세션까지 폐기되었다고 보장할 수 없습니다. 세션 식별자를 서버 저장소에서 제거하거나 계정의 세션 버전을 올리고, 매 요청의 서버 검증에서 이를 확인해야 합니다.
세션 폐기 시점도 명확히 정합니다. 계정 비활성화, 권한 변경, 비밀번호 재설정, 다중 인증 수단 초기화, 관리자 강제 종료 중 무엇이 전체 세션을 끊는지 정책을 써 두어야 합니다. 권한이 낮아졌는데 기존 세션의 권한 정보가 캐시에 남아 있으면 화면은 계속 높은 권한으로 작동할 수 있습니다. 데이터 읽기와 쓰기, 파일 다운로드, 장시간 연결을 모두 같은 기준으로 점검합니다. OWASP 세션 관리 지침도 만료나 로그아웃 시 서버 측 세션 무효화를 강조합니다.
자체 토큰을 쓰면 폐기 전략이 더 중요하다
서버가 서명만 확인하는 긴 수명의 자체 토큰은 발급 후 즉시 철회하기 어렵습니다. 유효 기간을 짧게 두고 갱신 토큰을 서버에서 폐기하는 방식, 토큰 식별자나 계정 버전을 조회하는 방식 중 운영 요구에 맞게 선택해야 합니다. 짧은 토큰도 만료 전까지는 살아 있을 수 있으므로 ‘즉시 종료’가 계약상 필요하다면 요청마다 서버 측 폐기 상태를 확인하거나 보호 대상에 더 짧은 인증 수명을 적용해야 합니다. 외부 SSO에서 로그아웃했다는 사실이 우리 서비스의 자체 세션까지 자동으로 없애는지도 별도로 검증합니다. 서로 다른 시스템의 세션은 자동으로 하나가 되지 않습니다.
세션을 거부하는 판단은 페이지를 처음 열 때만 하지 않습니다. API 호출, 다운로드 URL, 모바일 앱의 백그라운드 동기화, 웹소켓처럼 이미 열린 연결도 살펴야 합니다. 실시간 연결은 다음 메시지나 주기적 검증에서 종료 정책을 반영할 수 있습니다. 캐시를 쓰는 경우에는 폐기 정보 전파 지연도 측정합니다. 관리자 화면에 ‘종료 완료’라고 표시했는데 다른 서버 인스턴스에서는 몇 분 동안 허용하는 상태라면 실제 보안 약속과 다릅니다.
이미 브라우저에 렌더링된 자료는 서버가 세션을 폐기해도 사용자의 화면이나 로컬 캐시에 남을 수 있습니다. 따라서 강제 로그아웃 신호를 받은 앱은 민감한 화면을 가리고, 브라우저 저장소에 보관한 업무 데이터를 정리해야 합니다. 다만 화면을 가리는 동작은 보조 조치이며, 보안의 최종 기준은 서버가 후속 요청을 거부하는지입니다. 공유 기기와 오프라인 모드에서는 이 차이를 특히 분명히 해야 합니다.
점검은 ‘버튼을 눌렀다’ 다음부터 시작한다
두 기기에서 로그인한 뒤 한 기기만 로그아웃하고 다른 기기가 유지되는지 시험합니다. 이어 전체 세션 종료를 실행해 두 기기의 API 요청이 거부되는지 확인합니다. 퇴사자 계정 비활성화, 역할 변경, 비밀번호 변경, 비활성화 직전 발급된 다운로드 링크도 따로 시험하세요. 사용자가 이미 작성 중이던 내용은 가능하면 안전하게 임시 보관하고, 세션 종료 이유와 재로그인 방법을 분명히 보여 줍니다. 감사 기록에는 누가 어떤 범위의 세션을 언제 끝냈는지 남기되 실제 세션 비밀값은 기록하지 않습니다. 세션 종료는 화면 상태가 아니라 다음 요청부터 서버가 무엇을 거부하는가로 검증해야 합니다.
