보안꿈나무의 공부 일기 Break-Glass 계정
오늘은 현대에서 자주 사용하는 Break-Glass라는 계정에 대한 글을 써볼려고 합니다.
Break-glass 계정은 비상 접근 계정(Emergency Access Account) 라는 다른 이름을 가지고 있는데요
평소 사용하는 인프라 시스템에서 심각한 장애가 발생하거나 평소에 사용하던 인증 시스템 (MFA , IDP, SSO 등)이 죽어버렸을 때 를 위한 최종병기를 일컫는 계정입니다.
왜 이름이 Break-Glass 일까?
화재 발생 시 유리창을 깨고 소화기를 꺼내는 행동 이 행동을 Break_Glass 라고 지칭하기 때문이죠
이러한 이름을 가지고 있는 계정이기 때문에
일반적인 보안 프로세스로는 해결할 수 없는 슈퍼 울트라 긴급 상황에서 주로 사용하는 계정입니다.
그럼 대체 어떤 상황에서 사용할까?
- 통합 인증(SSO) 시스템의 전체 장애
- 네트워크 및 게이트웨이의 isolation 발생 시
- MFA 서비스 마비 또는 분실
- 랜섬웨어 및 사이버 공격 진행 상황
정도의 상황을 예시로 들 수 있습니다 이제 해당 상황에 대한 시나리오를 가설하고 탐구 해 보겠습니다.
Error 1 통합인증(SSO) 시스템의 전체 장애
우선 현대에서 우리가 사용하는 인프라는 여러가지 오픈소스 플랫폼이나 중앙집중형 자격증명 플랫폼에 연동을 해서 사용하는 경우가 대부분 입니다.
실제로도 요즘 Google 계정을 통한 로그인 , Github을 통한 로그인 등 로컬 ID/PW 보다 이런식의 OAuth2 방식으로 로그인 하는 경우가 월등히 많아지고 있죠
보통 대부분의 인프라나 시스템은 Authentik, Teleport, Okta, Entra ID같은 중앙 집중형 자격 증명 공급자(IdP)에 연동되어 있는 경우가 많습니다
- 문제 상황 시나리오
- 인증 서버 자체가 내부 데이터베이스 오염 , 만료된 SSL/TLS 인증서 또는 잘못된 업데이트로 인해 구동되지 않음
- 문제 상황 및 해결 방책
- 문제 상황:관리자가 서버에 로그인하고 싶어도 인증을 처리해 줄 SSO 시스템이 터졌기 때문에 일반적인 admin 계정으로의 접근이 불가능 한 상태
- 해결: 중앙 인증을 거치지 않는 서버 개별의 로컬 Break-glass 계정으로 직접 콘솔 접근하여 인증 설정을 롤백하거나 복구를 진행 해야 함
Error 2 네트워크 및 게이트웨이의 isolation 발생
외부 또는 내부망 사이를 연결해 주는 네트워크 장비나 방화벽, VPN, 프록시 서버에 문제가 생긴 경우에 해당 문제가 발생 할 수 있습니다. 이런 경우 역시 Break-Glass 계정의 필요성을 나타내주는 좋은 오류라고 볼 수 있겠죠
현대에는 내가 어디에 있던지 어느 기기를 쓰던지 서버에 접근 할 수 있는 상황인데 해당 상황이 막혀버리면 참 곤란할 거 같습니다.
- 문제 상황 시나리오
- NPM 및 방화벽 ACL 설정 오류로 인해 관리자 IP를 포함한 모든 외부 접근이 전면 차단되는 상황
- 문제 상황 및 해결 방책
- 문제:원격지에서 SSH나 웹 대시보드를 통한 정상적인 접근이 완전히 막힘
- 해결: 서버에 콘솔로 연결한 뒤 로컬로 생성되어 있는 Break-glass 계정으로 로그인하여 방화벽 규칙을 원상복구
Error 3 MFA 서비스 마비 또는 분실
보안을 위해 강력하게 걸어둔 2차 인증 기능이 인증을 못하게 하는 상황입니다
요즘 여러가지 보안 이슈 및 해킹 사건 , 개인정보 유출 등으로 인해 모든 플랫폼에서 2차인증을 사용하지 않는 플랫폼을 찾기가 더 힘든 상황입니다.
하지만 이런 2차인증으로 인해서 정작 2차인증을 걸어둔 본인이 못 들어가는 상황이 발생을 하게 됩니다
- 문제 상황 시나리오
- MFA 인증을 검증하는 외부 API 서비스의 다운, 내부 MFA 타임 서버의 동기화가 붕괴로 인한 모든 사용자의 OTP 번호가 일치하지 않는 오류
- 최고 권한을 가진 관리자가 하드웨어 보안 키를 분실 한 경우 혹은 갑작스러운 사고나 퇴사 등으로 연락이 두절되어 당장 시스템을 조작 할 수 없는 경우
- 문제 및 해결 방법
- 문제: 내가 걸어둔 2FA로 인해 인증이 되지 않아 해당 서비스를 본인임에도 이용 할 수 없음
- 해결:MFA 검증 과정을 우회 및 비활성화할 수 있는 하드웨어에 따로 보관한 Break-glass용 백업 코드를 꺼내어 진입
Error 4 랜섬웨어 및 사이버 공격 진행 상황
보안 침해 사고가 실시간으로 발생하는 상황입니다. 근래에 들어서면서 AI를 통한 실시간 고속 해킹의 방식을 주로 채택하고 있습니다
해커가 서버에 침투하고 모든 데이터를 들고 도망가고 추적을 방지하는 시스템을 뿌리고 도망가는데 단 1시간이면 충분하다는 결과가 보안 포럼에 보고되고 있습니다.
이런 상황에서 Break-Glass 같은 비상 계정을 만들어 두지 않는다면 큰 낭패를 보게 되겠죠
- 문제 상황 시나리오
- 해커가 일반 관리자 계정의 권한을 탈취하여 기존 관리자들의 계정을 모두 삭제하거나 비밀번호를 변경하고, 인프라를 장악해 나가는 상황
- 문제 및 해결 방법
- 문제: 정상적인 관리 권한이 모두 박탈당해 방어 조치를 취할 수 없는 상태에 빠짐
- 해결:해커가 접근할 수 없도록 격리되어 있던 최상위 Break-glass 계정으로 즉시 접속하여 해커의 세션을 강제 종료하고 네트워크를 차단
이러한 실 생활에서 매우 빈번하거나 자주 접할 수 있는 상황들을 위해서라도 Break-Glass 계정이 반드시 필요하게 됩니다.
그럼 이러한 Break-Glass 계정이 필요한 걸 알았으니 다음으로는 핵심 설계 및 관리 원칙에 대해 알아보도록 합시다.
1. Break-Glass 계정의 핵심 설계 및 생성 원칙
처음으로 Break-glass 핵심 설계 및 생성 원칙 입니다.
비상 계정은 일반적인 계정 관리 규칙인 1인 1계정, 최소 권한 원칙의 제약을 받지 않는 독립적인 존재 입니다.
하지만 권한이 매우 강한 만큼 설계 단계부터 철저한 독립성이 보장이 필요하겠죠
그렇기 때문에 해당 계정은 다음과 같은 엄격한 원칙을 준수 합니다
- 최상위 권한 부여
- 인프라의 모든 설정을 변경하고 복구할 수 있도록 가장 높은 수준의 권한(Root, Global Administrator 등)을 보유하며
- 외부 의존성 없음
- 회사에서 사용하는 통합 인증(SSO), 사내 Active Directory, 외부 IdP(Authentik, Okta 등)에 절대 의존하지 않습니다.
- 인증 서버나 네트워크가 마비되었을 때의 작동을 전제로 하기에 철저히 서버/플랫폼 로컬에 독립된 계정으로 생성을 해둡니다
- 상시 모니터링
- 절대로 평시에 로그인 이벤트가 발생해서는 안 되는 계정 입니다 그렇기에 로그인이 발생하거나 로그인 시도가 감지되는 순간 보안 관제 시스템 및 관리자 비상 연락망으로 즉시 알림이 가도록 설계를 해야 합니다
- 최소한의 계정 수 유지
- 접근 경로를 단순화하고 제어력을 높이기 위해 평균 2개 정도의 최소한의 비상 계정만 생성하여 관리 해야 합니다.
여기까지 보면 Break-Glass 의 권한이 매우 강하다는걸 아셨을거라고 생각하는데요 그러면 비상 계정의 권한이 강한 만큼, 자격 증명 또한 다른 보통의 계정과 같으면 안될꺼라고 생각하실 겁니다.
해당 계정의 자격 증명 또한 인간의 기억력 및 소프트웨어의 영역을 벗어나야만 해야겠죠?
2. 인증 및 자격 증명(Credential) 관리 원칙
- 고강도 패스워드 설정
- 최소 30자 이상의 무작위 문자열(대소문자, 숫자, 특수문자 조합)로 생성이 필수 입니다.
- 무차별 대입 공격(Brute Force)을 원천 차단해야 하며 반드시 사람이 외울 수 없도록 만들어야 합니다.
- MFA의 철저한 독립 설정
- 특정 관리자의 개인 스마트폰 앱(Google Authenticator 등)에 MFA를 연동은 절대 금지 사항에 해당 합니다 해당 직원의 퇴사, 연락 두절, 기기 분실 같은 상황이 발생하면 더이상 비상 계정 으로써의 가치가 없어지겠죠
- 전용 하드웨어 보안 키를 사용하거나, 물리적인 하드웨어 TOTP 토큰 발생기의 별도 지정이 필요 합니다.
- 소프트웨어 보관 금지
- 비상 계정의 패스워드를 일반적인 패스워드 매니저(1Password, Bitwarden 등)나 클라우드 메모장에 저장하면 안됩니다
- 해당 서비스가 해킹당하거나 다운되었는데 안에 복구 키가 있어요!! 라고 해봤자 소용 없겠죠
- 또한 위와 같은 이유도 있지만 복구 키를 시스템 내부 안에 적어둔 것은 해커한테 얘가 젤 맛있어요 얘부터 드세요 라고 하는것과 다를게 하나도 없습니다
- 비상 계정의 패스워드를 일반적인 패스워드 매니저(1Password, Bitwarden 등)나 클라우드 메모장에 저장하면 안됩니다
그럼 대체 Break-Glass 계정을 안전하게 보관하려면 어떻게 해야하고 어떤 방식을 거쳐야 할까요?
미국 첩보기관인 CIA에는 아주 유명한 대사가 있습니다.
여기는 50년 후의 기술과 50년 전의 기술이 공존하는 곳이야
대체 왜 이런 이야기가 나왔을까요?
바로 기록의 방식의 차이가 그 해답이 됩니다. 컴퓨터에 자료를 보관하면 어떤 방식을 통해서든 외부에서 가져갈 수 있지만 종이와 펜에 적은 자료들은 외부에서 가져갈 수 없어 그렇기에 최신 기술을 이용해 각 국가를 감시 하면서도 정작 기록을 구 시대 방식인 종이와 펜을 사용해서 기록하기에 이런 말이 나오게 된 것이죠
그렇기에 우리도 이런 Break-Glass 계정을 철저하게 아날로그적이고 물리적인 방식을 사용 해야 합니다
3. 보관 및 물리적 보안 원칙
- 물리적 격리 및 봉인
- 생성된 패스워드와 MFA 복구 코드를 종이에 작성 후 이를 내부를 볼 수 없는 불투명한 봉투에 넣고, 개봉 여부를 즉시 확인할 수 있는 보안 봉인지 로 마감
- 금고 보관 및 통제
- 봉인된 봉투는 물리적 자산 보호가 가능한 사내 보관 금고나 잠금장치가 있는 물리적 보안 구역에 보관하는 방식이 일반적으로 사용 되고 있습니다.
- 직무 분리
- 독단적인 비상 권한 남용을 막기 위한 장치입니다 금고의 비밀번호나 열쇠를 가진 사람, 봉인 봉투 안의 패스워드 구성을 알고 있는 사람을 분리하여 계정을 쓰려면 반드시 두 명 이상의 책임자가 물리적으로 동행해야만 하도록 강제하는 방식으로 구성 됩니다.
그럼 이렇게 까지 엄격하고 복잡하게 검수한 계정을 여러 번 사용 해도 될까요?
하하 그럴리가요
Break-glass 계정은 한 번 사용하고 나면 그 순간 수명이 끝나는 일회용 자산으로 취급해야 하고 이를 사후 관리 원칙이라고 합니다
4. 운영 및 사후관리 원칙 (LifeCycle)
- 정기적인 훈련 및 검증
- 정기적으로 비상 접근 훈련을 진행합니다 현대에서는 반기별로 1회 기간을 정기 기간으로 두고 시행하고 있습니다.
- 물리 금고에서 봉인을 해제하고 실제 로컬 콘솔로 접속이 원활하게 되는지 알림 시스템은 정상 작동하는지 확인합니다.
- 사용 후 즉시 폐기 및 재발급
- 비상 상황이 종료되면 사용된 Break-glass 계정의 패스워드와 MFA 코드는 반드시 즉시 폐기가 원칙입니다 예외는 없습니다.
- 새로운 무작위 패스워드를 발급하여 시스템에 적용한 뒤, 다시 종이에 인쇄하여 새 봉투에 봉인하는 재설정 프로세스를 거쳐야 합니다.
- Audit Log 분석
- 비상 계정이 활성화되어 있던 시간 동안 시스템 내에서 어떤 명령어들이 실행되었는지 타임라인별로 완벽하게 기록을 추출하고 복구 위원회의 승인을 받는 과정을 현대 에서는 채택하고 사용 중 입니다
마무리
기업과 개인 낭만과 현실 그 사이 어딘가에서
기업 환경이 아닌 개인이 운영하는 홈랩이나 기타 환경이라 할지라도 이러한 원칙의 본질은 동일하게 적용을 해야 합니다.
로컬 root 패스워드를 적은 종이를 서명 후 나만 알 수 있는 곳에 보관 하는것 혹은 최고 관리자 및 담당자만 아는 곳에 보관하는것 그리고 그 계정으로 SSH 접근이 발생하면 디스코드 봇이나 기타 설정한 관리 시스템으로 Emergency-Call 을 울리게 세팅하는 것여기가 바로 Break-Glass 계정을 만들고 사용하는 첫 시작점이라고 할 수 있을거 같습니다.
항상 보안을 하면서 느끼는 점이지만 완벽한 보안은 존재 할 수 없고 내 보안이 뚫리지 않는것은 잘 막은게 아닌 운이 좋은것이며
언제나 최악의 시나리오를 가정해야한다고 생각합니다.
여러분들의 인프라에도 끝을 대비한 최종병기가 준비 되어있나요?