첫 번째 비밀번호 유출은 해커가 아니라 운영 문제였습니다 — IAM/PAM 담당자를 위한 질문

Source: Dev.to

컴퓨팅 초기의 “비밀번호 유출” 사례 중 하나는 천재 해커 때문에 발생한 것이 아니었습니다.
비밀번호 파일이 정상적인 운영 과정에서 노출되었기 때문이죠—디버깅, 로그 출력, 파일 이동 등을 생각해 보세요. 악성코드도, 제로데이도 아닙니다. 일상적인 워크플로우가 민감한 데이터와 충돌한 결과였습니다.

다양한 버전의 이야기를 들어봤더라도 교훈은 같습니다: 자격 증명 실패는 종종 일상적인 작업처럼 보입니다.

오늘도 존재하는 “프린터 순간”

우리는 인쇄된 비밀번호 목록에서 다음과 같은 형태로 진화했습니다:

• “오늘만” 티켓에 붙여넣은 비밀
• “릴리스가 될 때까지” 스크립트에 남겨진 관리자 자격 증명
• “모두가 접근해야 하니” 공유 계정
• 몇 달 동안 “임시”로 유지되는 과도한 권한 그룹
• 절대 만료되지 않는 벤더 접근 권한

이러한 사례는 드물지 않습니다. 편리함이 정책이 될 때 일어나는 일입니다.

IAM/PAM이 존재하는 이유

• IAM은 구조를 제공합니다.
• PAM은 권한에 규율을 추가합니다.

잘 구현된 PAM은 단순한 제품이 아니라 다음을 강제하는 시스템입니다:

• 소유권: 이 정체성에 누가 책임이 있는가?
• 시간 제한 (JIT): 왜 이것이 영구적인가?
• 검증: 누가 무엇을 했는지 증명할 수 있는가?
• 증거: 감사와 사고 대응 시 이를 방어할 수 있는가?

통제 수단이 증거를 생성하지 못한다면, 필요할 때는 존재하지 않는 것입니다.

“프린터 순간”을 방지하는 작은 체크리스트

누군가 접근을 요청하면 다음을 물어보세요:

• 이것이 역할/그룹에 매핑되는가, 아니면 일회성인가?
• 권한이 필요한가, 아니면 표준 접근만 필요한가?
• 영구적인가, 아니면 시간 제한이 필요한가?
• 검토 주기는 어떻게 되는가?
• 증거는 어디에 있는가 (티켓/승인/내보내기/로그/스크린샷)?

이것이 “우리는 안전하다고 생각한다”와 “우리는 증명할 수 있다” 사이의 차이입니다.