SharedIT | 묻고 답하기(AMP)

AWS의 Role 사용에 대한 보안 문의

안녕하세요.

전직장에선 온프렘환경에서 근무화였지만, 현제는 AWS Cloud가 주가 되는 회사에서 근무하고 있습니다.

AWS를 쓰나, 온프렘환경에서나, 여러가지 접근을 통제할 수 있는 방법이 존재합니다.

사용자가 서버 접근 시 서버 접근제어 솔루션을 통하는 방법이 있을 수 있고,

추가로 AWS 환경도 마찬가지로 서버제어 접근솔루션 사용 혹은 IAM Policy를 통하여 SSM을 통하여 서버 접근을 제어 하는 방법이 있구요,

특히 AWS를 사용하면서 EC2나, Lambda 등 동작하면서 AWS의 리소스 접근 시 Role할당을 통하여, 굳이 IP로 제어할 필요 없이 정책으로 제어할 수 있는 부분이 엄청나게 큰 장점이라 느껴집니다. 

다만 최근 고민이 되는 부분이 현재 민감한 Secret들을 Vault(OSS 자체 구축)를 이용하여 관리를 하고 잇는데, 리소스 부족으로 Vault만 집중적으로 할수 없어서;; HA구성도 하시코프 측 가이드에 따라 하지 못하였고, 관리도 복잡하다 보니 AWS 서비스를 생각하게 되더군요.

대안으론 Secret Manager, Parameter Store를 써볼까 하니, 비용적인 부분은 고사하고, 한가지 궁금한 부분이 생깁니다.

위 Secret Manager, Parameter Store 모두 key:vaule를 저장하고, Vault값에 대하여 KMS를 이용한 암호화를 지원하기에 Secret에 대한 관리야, 담당할 인원에게만 롤을 부여하면 되니 문제가 없고,

Secret정보도 암호화 되어 저장되니, 권한이 없는 사용자,리소스는 해당 key접근이 불가능하고, 있다 하더라도 KMS까지 권한이 필요한니 정책만 잘 부여하면 사용상 문제는 없고, 오히려 더 편할것으로 보입니다. 

특히 Parameter Store의 경우 멀티어카운트 환경에서 고급기능 사용시 디렉토리 형태로 prod/staging, service 종류, secret 종류별로 secret 생성 하고, 필요한 계정의, 필요한 리소스에  role만 부여하면 되니깐 중앙 관리도 되고요.(Secret Manager와 달리 rotate 기능 제공 부제는 아쉽습니다.)

다른 부분도 마찬가지 이겠지만 EC2 -> DB 접근 시 credential정보를 위 서비스에 올리고, EC2에 접근을 위한 Role 할당을 했다는 전제하에 한가지 궁금증이 생깁니다.

AWS Role은 리소스에 적용되는 것이지, 리소스 내부 Application에 부여되는 것이 아닌데, 만일 외부 침해가 발생하여, EC2의 Shell 권한을 획득하였다 전제를 하였을때, 

어차피 EC2 -> DB접근은 통신이 필요로 하니 SG는 Open 상태, DB접근 시 필요로 한 Credential 정보 또한 EC2 내부에 들어온 상태이니 동일하게 Role을 사용하여 Secret Manager, Parameter Store에 접근 및 kms를 이용한 secret 정보 탈취 및 DB접근이 가능한 것이 아닌가 싶습니다.

분명 IAM을 이용한 해당 리소스가 접근할 수 있는 다른 리소스는 제한이 되어, 사고가 확산되는 부분은 막을수 있는 것은 가능한데, 그렇다고 Secret 정보 획득까지 차단할 수 있는 것은 아닌거 같거든요. 

특정 리소스가 모든 리소스에 접근하는 것을 막을 수 잇는건 분명 장점이고, Secret Manager, Parameter Store또한 간편하게 Secret 정보를 안정하게 저장할 수 잇는부분도 장점이라 느껴지긴 하는데, 

내부 침해 발생 시 Secret 정보 탈취를 막을 수 있는 방법이 있을까요??  Secret Manager, Parameter Store 이런 서비스가 정말로 안전하게 사용할 수 있는지도 의심이 됩니다. 

혹 이러한 부분에 있어 더 보안할 수 있는 방법이 있을까요? 

 

Tags : 태그가 없습니다.

1개의 답변이 있습니다.

hoollachan
  0 추천 | 일 년 이상 전

저도 잘은 모릅니다만 아는 한도내에서 생각을 말씀드려요~

말씀하신 것처럼 EC2에다가 DB를 접근할 수 있도록 Role을 부여하고 RDS의 SG에 EC2 IP를 허용하고 하는등은 정말 
서비스상에 필요한 과정이라서 어쩔 수 없다고 생각합니다.

그렇게 DB에 접근할 수 있는 리소스를 최소화했다는 전제하에,

말씀하신 내용을 봐서는
그 최소화된 리소스가 탈취되는 경우 또는 권한을 가진 내부자가 의도를 가지고 접근하는 경우에는 어떻게 하느냐의
문제로 보여지네요~

결국 그렇게 되면 그 최소화된 리소스 또는 경로에 접근할 수 있는 권한도 최소화하는 수 밖에 없을거 같습니다

위에 말씀하신 예로 들어보자면 EC2에 접근할 수 있는 경로를 최소화하는 방법이 될 수 있겠네요

AWS 콘솔에 접근할 수 있는 IP를 제한하고, VDI등을 이용해서만 EC2에 접근하도록 하거나 또는 서버/DB 접근제어를
통해서만 AWS 워크로드에 접근하도록 제한하는 방법을 쓰면 어느정도 보완이 되지 않을까 생각합니다~