본문으로 바로가기

AWS IAM 정책(policy)을 정리 해보겠다.


왜냐하면 최근에 보안 관련해서 AWS IAM권한중에 IP를 제한하는 작업을 해야 하는데 AWS에 정책들이 워낙 많고 애매하면 AdministratorAccess를 줬다가 할꺼 하고 다시 빼고 하는 등 꼬이고 문제가 해결 되면 또 잊어버리고 이런 일이 너무나 반복되어 한번 정리를 하고자 한다.


좀 씁쓸한 이야기 이긴 하지만 우리는 금고는 너무 좋은데 금고에 보관할게 없다. ㅋㅋㅋ 암튼 금고가 중요하다고 하니 이 작업을 하긴 하지만 하면서도 뭔가 보람이 없다. 그리고 이게 손은 많이 가고 권한을 제한하는 작업이기 때문에 안돼면 나한테 가지고 와서 풀어달라고 하고 작업하다가 끊기는 것 만큼 회사에서 예민한 문제가 없기 때문에 이 작업이 돌고 돌다가 처리가 안돼고 있어서 내가 처리 하고 있다.


나는 뭐 하이얘나냐 ㅋㅋ


IAM을 들어가면 위와 같은 알흠다운 메뉴가 나온다.

여기에서 '사용자'는 사용자를 만들고 지우고 권한주고 할 수 있는 메뉴고 '역할'은 사용자 말고 사용자 처럼 쓸 수 있게 하는 기능인데 서버에 권한을 줄 때 서버에 사용자를 연결 할 수 없기 때문에 '역할(role)'을 만들어서 서버에 연결을 해준다.


예를 들어보자면 '법인'같은 것이다. 나는 사람이고 그냥 '인'인데 나 말고 회사나 단체 같은건 법적으로 '인'하고 비슷하게 다루게 해주기 위해서 이 '법인'이라는 개념이 있는데 사람 눈으로 봤을 때는 아무것도 안보이지만 법의 눈으로 봤을때는 '인'이나 '법인'이나 똑같은 사람이듯이 이 역할(role)은 일종에 '법인'이고 사용자(user)와 같은 개념이라고 보면 된다.



그럼 정책(policy)에 대해 알아보자.


먼저 AdministratorAccess


어차피 뭔지 알긴 하지만 AWS IAM들어가서 가장 자주 보는 정책(policy) 리스트 화면이다. 여기에서 가장 위에 있다. 처음 AWS를 쓸 때 일단은 이걸 넣고 쓴다. 왜냐하면 뭐 애매하게 만지면 어디서 뭐가 안돼는지도 모르겠기 때문에 일단 다 갖고 시작한다. 그런데 어차피 백엔드 개발자는 모든 권한을 가지게 되어있다.


장애가 나면 백엔드 장애가 대부분이고 어쨌든 서버에 심폐소생술은 백엔드 개발자가 하기 때문에 다 뺏었다가도 결국에는 줄 수 밖에 없다.


AdministratorAccess는 모든 권한이다.

그 모든권한이 뭐냐면 서버를 죽이고 살리고, 서비스를 띄우고 내리고 뿐만 아니고 사용자를 만들고, 사용자를 지우고, 만든 사용자에게 또 AdministratorAccess를 줄 수 있다. 계정 발급하고 AdministratorAccess를 준 다음에 id랑 패스워드를 알려주면 그 사람이 들어와서 현재 모든 개발자들의 계정을 지워버리고 EC2, ECS를 다 내려버릴 수 있다.


모든 개발자들의 계정을 지웠기 때문에 누군가 들어와서 다시 서버를 복구하는 등의 작업을 할 수 없게 할 수 있다.


AWS IAM이 사용자의 권한을 통제하는 기능인데 이 IAM권한까지 들어있는게 AdministratorAccess이다. 신중히 줘야 하는 권한이지만 일단은 이걸 놓고 쓰면 뭔가 되기 때문에 가장 많이 쓰이는 권한이다 ㅋㅋ



그 다음이 PowerUserAccess이다.


power라고 검색 하면 바로 나오니 이 권한을 주로 사용하는게 좋을 것 같다.


AdministratorAccess - IAM이 PowerUserAccess이다.


IAM권한이 없다. 때문에 PowerUserAccess정도만  줘도 user 생성이나 또 다른 AdministratorAccess는 생성할 수 없기 때문에 개발자가 할 수 있는 막장짓은 돌아가고 있는 AWS EC2, AWS ECS서비스에 들어가서 서버를 내리는 것과 RDS에 들어가서 DB를 지우고 백업해 놓은 데이터를 날려버리는 정도 뿐이다.


중간에 누군가 알아챈다면 권한이 있는 다른 개발자가 와서 서버도 다시 띄우고 AdministratorAccess가 있는 사용자가 있으면 서버를 죽이고 DB를 날리고 있는 계정이 있다면 그 계정을 지워버리거나 로그아웃 시켜버릴 수 있다.



다음은 IAMFullAccess다.

이름에서 알 수 있듯이 IAM에서 뭐든지 다 할 수 있다. 사용자 보기, 사용자 만들기, 사용자 지우기, 사용자에게 권한 부여하기다.


회사에 보안팀이 있다면 이 놈에 IAM 들어올일이 꽤 많다. 그냥 개발자들만 있으면 이 IAM가지고 별로 뭐라고 할 일이 없을 것이다. AdministratorAccess줘버리거나 그나마 조금 통제를 한다고 하면 PowerUserAccess정도 주고 하고 싶은 것 하라고 할 것 같다.


PowerUserAccess를 쓴다면 IAMFullAccess는 다른 계정에 넣어놓고 그 사람만 IAM을 할 수 있게 해주면 권한 같은거 그분한테 달라고 할 수 있고 이걸 boto3같은거 서버에 올려놓고 필요할때 커맨드 날려서 받고 빼고 할 수 있고 거기에서 로그를 남기면 통제를 할 수 있지 않을까 하는 생각을 해본다.


권한이 이렇게 되어 있으면 IAM에서만 뭔가 작업 할 수 있을 것 같지만 이것도 전체 권한을 갖고 있다고 보면 된다. 진짜인지 실험을 해보기 위해 내가 작업 하다가 빡쳤을때 어디까지 날려버릴 수 있는지 Test를 해보기 위해 ECS를 들어갔다.


아니 xx 안돼네? 클러스터 띄워놓은거 내려버려서 사용자들이 들어와서 물건도 못사고 접속해서 왜 안돼냐고 지... 아니 뭐라고 못하시게 서버를 쭉 내리고 싶었으나 권한이 없다. ㅋㅋ AdministratorAccess를 넣을 수 있는지 실험을 해보자.


ㅋㅋㅋ 아주 손쉽게 정책 연결 눌러서 맨 위에 나오는 AdministratorAccess가 추가 할 수 있다.


서버를 다 꺼버리기 위해서 다시 ECS로 들어가면 아까는 나오지 않던 서비스 개수가 나온다. 된다는 뜻이다.

그런데 이게 적용되는데 약간 딜레이가 있다 내 체감상은 한 20초 정도 됐던 것 같은데 이거 넣고 커맨드를 바로 날리거나 f5를 바로 누르면 일단 권한 줬는데도 안됀다고 나오는데 잠깐 기다려 보면 된다.


사실상 IAMFullAccess도 AdministratorAccess와 같은 기능이기 때문에 이 정책들에 대해 잘 모르는 사람들이 AdministratorAccess를 아무한테나 주면 돼냐고 자꾸 일하는데 와서 머라고 하믄 이 IAMFullAccess 달라고 하면 된다. 그러면 필요에 따라 어드민을 줬다 뺐다 하면서 업무에 지장이 없이 할 수 있다. 일도 다 사람이 하는데 유연성이 있어야지 맨날 틀어막는다고 막아지는게 아니다.




일단은 작업을 마져 해야하니까 나중에 또 작업하다가 왜 이거 내가 하고있나 이런 생각 들면 업데이트 할 예정ㅋㅋㅋㅋ 아 ㅋㅋㅋㅋ 지져스 크라이스트 땡큐 ㅋㅋ


end.





댓글을 달아 주세요