세미나 주제는 Non-Human Identity와 버그 바운티 이 두개만 진행했으며, 버그 바운티는 꿀팁 알려줄 지 알았는데 알고 보니 기업에서 버그 바운티를 운영해야 하는 이유를 알려줘서 나에겐 별 의미가 없었다.. 따라서 논 휴면 아이덴티티 요약만 하겠다!
1. Non-Human Identity란?
출입카드를 예시로 들어보면, 회사에 들어갈 때 출입카드(RFID 카드)로 출입을 한다. 사람과 1:1로 매칭되는 식별카드를 Human Identity 라고 한다.
그러나 클라우드 시크릿 키의 경우 누가 이 키를 소유하는지에 대해서 모른다(1:1로 발급하는 경우는 모르겠는데, 범용으로 사용하는 경우를 말하는 거다) SSH 개인키도 마찬가지다. 내부자가 마음만 먹으면 이를 유출시키기도 쉽고 접근하기도 쉽다. 얘기가 길어졌는데, 직원과 1:1로 매칭되지 않는 Access Key를 **논 휴면 식별자** 라고 한다.
2. 과거 피해
1) 해고당한 직원이 논 휴면 식별자로 외부에서 접근하여 테스트 시스템 및 서버 삭제
2) 6657개의 사이트(70만개 중)에서 프론트엔드 자바 스크립트 코드에서 AWS Secret 키가 노출된 경우가 있음.
3. 무엇이 문제인가?
최근 침해사고의 31%는 논 휴면 식별자(시크릿) 관리에서 발생한다. 당연한 얘기지만 최근 보안시스템이 강해졌기도 했지만 이 문제로 보안시스템을 뚫지 못해서 시크릿을 노리는 게 아니다.
코로나로 원격근무가 활성화되고 시크릿 키로 접근하기 쉽기 때문에 뚫기 어려운 곳보다는 뚫기 쉬운 곳으로 포커스를 맞추는 것이다.
내가 생각한 원인과 세미나에서 제공한 원인은 다음과 같다.
1) 시크릿 키 관리 부족
군에 복무해본 사람은 알곘지만, 기밀자료는 일일이 관리번호와 누가 소유했는지를 문서 대장에 기록한다. 아무렇게나 발급 및 공유하고 체계화된 관리가 이루어지지 않은 걸로 추측된다.
2) 최소 권한 규칙 미준수
필요한 만큼 권한을 부여한다는 규칙은 보안업계에서 유명하고, 꼭 지켜야 하는 규칙 중 하나이다.
그렇지만 실제로는 빠른 일 처리를 위해 슈퍼 유저 권한을 부여한다(짱 쎈 권한).
중간에 일처리가 안될때 마다 일일이 권한 요청하는 것이 번거롭기도 하고 릴리즈 데이가 다가오는데 보안을 신경 쓰기는 어렵기 때문이다.
여기서 보안담당자가 사전 필요 권한을 명확히 정의하고 이를 롤로 만들어 놔야 하는데, 이를 안해서 라고 추측된다.
발급된 시크릿 키 중 50%가 슈퍼 유저라고 한다.
3) 프론트엔트 측 자바 스크립트 그리고 CI/CD에서의 AWS 키 노출
관리 부족이다. 릴리즈 전에 최소한 하드코딩된 중요정보가 있는지 체크해야 하는데 그조차도 안한 것이다.
*CI/CD 파이프라인이란 깃헙, 젠키스 같은 소스코드를 합칠 수 있고, 테스트를 해주는 플랫폼이다.
4) 시크릿 키 미교체
패스워드도 90일 주기로 교체하는 것이 권고되고, TLS 인증서도 마찬가지다. 교체 이유는 조금 다르긴 하지만 공통적인 건 공격자가 시크릿을 탈취했을 때 지속 사용을 방지하기 위해서다.
물론 지속사용이 중지되기 전 인스턴스 내 백도어를 설치해서 지속 접근이 될 수도 있기는 하지만.. 필요하다고 본다.
어쨌든 시크릿 키도 주기적 교체가 필요하며, 최근 트렌드는 어떤 요청 마다 즉시 시크릿 키를 교체 한다.
예시) 시크릿 키 보관 중 -> 키를 이용한 AWS로 요청 -> 요청이 종료되면 새로운 키를 발급하고 이를 요청자에게 전송 -> 요청자는 기존 키 폐기와 새로운 키를 받음
5) 불필요한 시크릿 키 발행
AWS에서는 시크릿 키가 없어도 업무에 지장이 없게끔 새로운 방안들을 만들고 있다.
예시로 IAM Role을 부여하고 STS(Security Token Service)로 임시 자격 증명을 발급하는 것이다.
따라서 시크릿 키 발급은 최후의 수단으로 두고 그 외 다른 방안을 마련하는 것이 중요하다고 본다.
6) OIDC에서의 최소 권한 정책 미준수
OIDC는 OpenID Connect이며, 인증 프로토콜 중 하나이다. 인증은 JMT 방식을 사용한다.
JMT가 무엇인지는 https://securitypt.tistory.com/38 참고 바란다.
어쨌든 테라폼에서 클라우드 인스턴스, DB 같은 자원들을 배포할 때 OIDC 방식으로 인증을 하는데, 이를 위해선 IAM로 롤 부여를 해야 한다.
여기서 이 롤에 많은 권한이 부여되어 있어서 최소 권한 부여 원칙에 위반된다는 것이다.
4. 참고 자료
https://owasp.org/www-chapter-seoul/assets/files/OWASP%20Seoul%20-%20%EA%B9%80%EB%8F%99%ED%98%84%20Non%20Human%20Identity%20Top%2010%20%EC%82%B4%ED%8E%B4%EB%B3%B4%EA%B8%B0.pdf
5. 읽으면 좋아 보이는 것
https://www.cremit.io/ko/blog/understanding-the-owasp-non-human-identities-nhi-top-10-threats
6. 후기
새로운 것을 배운 것 같아서 좋았다! 물론 지금은 이것보다 기초부터 배워야 되긴 하지만... 트렌드를 아는 것도 중요하니 유익한 시간이였다!
'기타' 카테고리의 다른 글
| 에베레스트 베이스 캠프 솔로 트래킹 후기 (0) | 2025.12.31 |
|---|---|
| 코레일 자동 예매 스크립트 (0) | 2025.12.24 |
| 정보 보안 학습을 위한 GPT 만들기(프롬프트 엔지니어링) (0) | 2025.02.25 |
| 초기 정보 수집 스크립트(Nmap, BurpSuite) (0) | 2025.02.16 |
| 뒤 늦은 정보보안기사 합격 후기 (0) | 2025.02.07 |