벤더의 설명 대신 실제 환경에서 확인할 수 있는 예·아니오 7문항입니다.
상시 권한 없음은 이제 많은 PAM 벤더가 내세우는 말입니다. 하지만 실제 환경에서 그 주장을 시험했을 때 어떤 일이 일어나는지는 슬라이드만으로 알기 어렵습니다. 상시 권한 없음은 자격증명이 아니라 세션 자체의 속성이어야 한다고 이미 주장했습니다. 자격증명의 수명이 짧아도 그 신원이 가진 권한을 그대로 쓸 수 있다면 상시 권한 없음이라고 보기 어렵습니다. 이 글에서는 환경에 직접 적용할 수 있는 7가지 질문을 정리합니다.
먼저 확인할 다섯 가지 속성
이 점검은 다섯 가지 속성에서 출발합니다. 그중 첫 번째는 사실 상시 권한 없음의 속성이 아닙니다. 그리고 그게 요점입니다. 범위는 세션이 어디까지 갈 수 있는지만 알려 줄 뿐, 그 안에서 어떤 명령이 실행되는지 들여다보는 장치가 있는지는 말해 주지 않습니다.
- 명령이 선언된 범위 안에 들어와 있어도, 그 명령 자체를 들여다보는 무언가가 남아 있어야 합니다. 범위 안이라는 이유만으로 무엇이든 실행할 수 있는 건 아닙니다.
- 선언된 범위를 벗어나는 모든 것은 기본적으로 거부됩니다.
- 범위는 서버가 허용하는 범위와 세션이 요청한 범위가 겹치는 부분까지만 열립니다.
- 세션은 별도 채널의 승인 없이 스스로 범위를 넓힐 수 없습니다.
- 세션 모델이 다루지 않는 자격증명은 숨기지 않고 이름을 붙여 드러냅니다.
아래 점검 항목은 이 다섯 가지에, 세션 모델만으로는 닿지 않는 자격증명과 계정 두 가지를 더해 총 일곱 가지를 확인합니다.
점검 항목
다음 문항은 벤더 자료가 아니라 실제 환경에서 확인해야 합니다.
- 허용 범위 안의 명령도 따로 확인합니까? 범위 안에 있지만 파괴적인 명령을 실행해 봅니다. 채널·호스트·사용자가 모두 맞으면 요청 자체는 문제없이 보입니다. 세션과
rm -rf사이에 허용 범위밖에 없다면, 그 범위가 유일한 통제이며 충분하지 않습니다. - 세션이 지정된 범위를 벗어나는 순간 곧바로 거부됩니까? 한 가지 작업으로 범위를 지정한 세션을 열고, 그 범위 밖의 것을 시도해 봅니다. 다른 채널, 다른 호스트, 정책이 허용 목록에 올린 적 없는 명령입니다. 이것이 실행된다면 기본 거부(default-deny)는 없고, 권고 사항 하나만 갖고 있는 셈입니다.
- 토큰을 재사용(replay)해도 세션의 허용 범위를 벗어나지 못합니까? 추측하지 말고 직접 확인합니다. 세션 토큰을 꺼내 해당 세션이 허용하지 않은 호스트에서 써 보고 결과를 봅니다. 토큰이 사용자에게 부여된 모든 역할까지 그대로 쓸 수 있다면, 실제 제한은 세션 범위가 아니라 역할입니다. 이 경우 세션 범위는 제한 구실을 하지 못합니다.
- 세션은 외부 승인 없이 허용 범위를 넓힐 수 없습니까? 세션을 열 때 쓴 자격증명만으로 범위 확장을 승인해 봅니다. 가능하다면 탈취된 세션이나, 탈취된 뒤 스스로 판단해 움직이는 에이전트도 외부에서 알아채기 전에 권한 범위를 넓힐 수 있습니다.
- 슈퍼유저의
sudo도 세션 범위를 벗어나지 못합니까? RBAC은 역할에 부여할 수 있는 권한을 정합니다. 이 문항은 명령을 실행하는 순간 세션이 무엇을 허용하는지 확인합니다. 슈퍼유저로 로그인한 뒤 범위를 좁게 지정한 세션을 열고, 허용하지 않은 곳에서 sudo를 시도합니다. 거부나 별도 승인 없이 실행된다면 실제 통제는 RBAC뿐이고 세션은 아무 역할을 하지 못합니다. - 이 환경의 모든 서비스 토큰이나 CI 자격증명은 발급 이후에도 다시 평가하는 장치가 있습니까, 아니면 누군가 교체를 떠올릴 때까지 그냥 작동합니까? 수명이 얼마나 되는지, 무엇이 그 범위를 제한하는지 물어봅니다. 발급 이후 아무도 다시 평가하지 않는 자격증명은, 마케팅이 뭐라고 부르든 이름만 다른 상시 권한입니다.
- 전체 서버군의 로컬 OS 계정을 모두 파악하고 있으며, 각 계정의 주인이 누구인지 압니까? 인벤토리 도구 말고 서버 한 대를 임의로 골라 그 서버에서 직접 목록을 뽑아 보고, 현재 팀에서 주인을 대지 못하는 계정이 몇 개인지 세어 봅니다. 누가 만들었는지 아무도 기억하지 못하는 계정은 정의상 상시 권한입니다. 보이지 않는 것은 통제할 수 없고, 인벤토리 도구는 자신이 전달받은 것만 보여줄 뿐입니다.
이 점검만으로는 알 수 없는 것
이 항목 중 하나라도 '아니오'라면 실제 통제 공백입니다. 어떤 세션 모델도 모든 공격 표면을 막지는 못합니다. 대화형 셸에서는 sudo가 아니어도 위험한 명령을 실행 전에 막지 않고 사후 감사만 하는 경우가 많습니다. 항목 1이 확인하려는 공백이며, 저희도 예외가 아닙니다.
Alpacon의 세션 모델은 범위 상한에 관한 2번, 4번, 5번 질문에 답하도록 설계돼 있습니다. 세션 범위는 서버가 허용한 범위와 세션이 선언한 범위의 교집합으로 최소화되고, 그 밖의 요청은 기본적으로 거부됩니다. 범위를 넓히는 일은 세션 안에서 결정할 수 없고, 세션 밖의 승인 절차를 거쳐야 합니다. 세션의 만료 시각도 워크스페이스가 정한 최대 기간을 넘어설 수 없어서, 방치된 세션은 스스로 만료에 도달하고 열려 있던 채널도 함께 정리됩니다. 이 경계는 배포 설정이나 단계적 전환의 문제가 아닙니다. 범위 상한은 이미 적용되고 있고, 세션이 선언한 범위를 벗어난 sudo는 그 자리에서 거부됩니다. 슈퍼유저도 예외가 아닙니다. 범위 안에 들어온 뒤에도 명령 자체를 판단하는 1번 질문은 별도의 축입니다. 범위 안에서 어떤 동작을 허용할지 정하는 명령 단위 판단에 해당합니다.
벤더 자료보다 먼저 확인할 것
이 점검은 상시 권한 없음이 자격증명이 아니라 세션에 있어야 하는 이유를 다룬 글을 대신하지 않습니다. 그 글의 실행판으로, 자신의 환경에 직접 돌려보거나 평가 중인 벤더에게 그대로 건네 쓰라고 만든 것입니다. 여기 문장은 그대로 실행 지침으로 읽으면 됩니다. '아니오' 답 대부분이 셀프서비스 범위 확장, 주인 없는 계정, 아무도 추적하지 않는 서비스 토큰처럼 한 곳에 몰려 있다면, 실제로 손봐야 할 지점이 거기입니다. 대개는 벤더와의 대화가 암시하던 것보다 작은 일입니다.
