현실성 있고 간단한(?) 클라우드 보안법

시작하기 전에

이 글은 매우 개인적인 견해가 들어간 글입니다. 절대 이 글이 답도 아니고, 그냥 한 사람의 의견일 뿐 입니다.

최대한 간편하고, 현실성있으며 쉽게 따라 할 수 있는 방법으로 넣어봤습니다만.. 어려우신 분들은 아래 링크를 먼저 참고하신 뒤에 글을 읽어 보시는 것을 권장합니다.

참고로 이 글은 AWS를 기준으로 작성 되었습니다. 서비스 편협적인건 좋지 않지만, 그래도 써본게 이거 하나라..

왜?

사람들은 권한을 그냥 줄까?

사실 짧지만 몇달동안 운영해 보고, 개인적으로도 클라우드를 쓸 일이 많아서 해보니 아래 이유가 제일 컸습니다.

귀찮아서

인간은 정말 귀찮음을 싫어하는 동물입니다. 저도 귀찮은게 싫어서 인공지능 스피커한테 일 시키는데요 뭐..

가끔씩 서비스를 실습해 볼려고 국내 외 블로그를 보다보면 AdministratorRole을 주는 경우나, 특정 서비스의 전체 권한을 주는 경우가 있는데요.

심지어 이렇게 해 두고 코드에 키를 박아두고 이를 그.대.로 GitHub에 올리는 경우가 종종 있습니다.

어.. 이러다가 나쁜 채굴자 만나서 c5.16xlarge * 60개 돌아가게 된다면..? 신용불량자 (채무불이행자) 가게 되는..

물론, 자비로운 AWS 형님들에게 잘 설명하면 된다곤 하는데.. 이게 또 확실하지 않은 거라서..

이러한 일을 사전에 방지하고자 몇가지 방법을 생각해 봤습니다.

제한 범위

읽기, 쓰기는 기본이구요.

왠만하면 Full 이라는 단어가 붙은 것은 쓰지 않는 것을 권장합니다.

근데 이 것보다 중요한건 사용 하고자 하는 비즈니스 로직에서 필요한 권한만 빼서 쓰는 것이 중요합니다.

결국엔 내가 만들고자 하는 서비스에서 어떠한 asset과 action을 할 것인지를 파악해서 잘 줘야 합니다.

그냥 남이 만든 것은 왠만하면 쳐다보지 마고 그냥 내 권한은 내가 직접 만든다! 라는 마인드로 가야 합니다.

기존 정책 직접 연결에서 아마 AWS가 만들어 둔 권한이 있을 것입니다만, 옆에 정책 생성 눌러서 만드시면 됩니다.

요즘엔 JSON 편집기 말고 권한 편집 기능이 잘 나와 있어서 그나마 권한 주는 것이 편리하게 되어 있더라구요.

근데 asset의 scope를 정해야 하는 경우에는 직접 편집해야 하는 경우가 있어서 그 부분은 나중에 따로 시간이 매우 많이 남는다면 포스팅 하도록 하겠습니다.

시뮬레이션

내가 만든 권한이 잘 동작 하는지 잘 모르겠다구요?

AWS에서는 IAM Policy Simulator 라는 기능을 제공합니다.

직접 그 돈을 내가며 서비스를 사용하지 않아도 어떠한 권한을 가지고 있는지 검사할 수 있는 좋은 검사기죠.

내가 만든 정책이 문제는 없는지와 실제로 접속이 가능한지를 비용 청구 없이 테스트 해볼 수 있는 기능입니다.

이런 식으로 실제 기능을 시뮬레이션 해 볼 수 있습니다.

저기선 제가 S3FullAccess를 줬기 때문에 s3 서비스에만 모두 접근이 가능하단걸 확인 할 수 있습니다.

(제가 Full 쓰지 말라고 해두고 제가 Full을 쓰고 있네요. 물론 저거 지금 지웠습니다 호호)

이런 식으로 production에 배포되기 전에 한번이라도 검사하는 습관을 가지도록 합시다. 즐겨찾기 꾹 ㄱㄱ

코딩

AWS 서비스를 연결하기 위해 boto라는 SDK를 사용해야 하는 경우가 많습니다.

실제로 저도 많은 AWS 서비스를 유연하게 연결하기 위해서 해당 라이브러리를 매우 애용하는 편인데요.

이 SDK에서는 대표적으로 아래와 같은 연결 방식을 제공합니다.

서비스 IAM
환경 변수 기반
프로파일에 인증키를 박아두고 호출할 때 불러오는 방식
코드에 시크릿키를 박아두고 사용

여기서 딱 보면 알겠지만, 마지막에 코드에 시크릿키를 박아두고 쓰는건 그냥.. 내 비번은 이 것 입니다. 라고 알려주는 것과 크게 다르지 않습니다.

실제로 많은 분들이 이러한 코드가 Github Public Repository에 그대로 올라가면서 요금 폭탄의 대상이 되는 경우가 많습니다.

이러한 방법을 막기 위해 위에서 설명한 연결 방식에서 제일 위에 있는 방식을 권장하는 편 입니다만.. 실질적으로 개발 단계나 일부 production이 AWS 인프라에 없는 경우가 많아서 2번 혹은 3번을 사용할 때도 있습니다.

그래도 4번보단.. 괜찮으니 2,3번 방식이라도 반드시 사용합시다.

그리고 실제로 예시를 보여 드리자면 코드도 깔끔해 집니다. 키가 뭐지 생각 안해도 되거든요.

import boto3

client = boto3.resource('s3', region_name='ap-northeast-1')

2차 인증

이거 생각보다 많이 들 안켜시더라구요. 왠만하면 활성화 해 두시는 것을 추천합니다.

어짜피 비밀번호, 아이디 다 뚫려도 이 2차 인증에서 남의 업장에서 채굴 하실려고 하는 분들은 그만 두실 겁니다.

2차 인증 뚫으면 채굴보다 그 기술을 파는게 돈이 더 되거든요. ㅋㅋ

여튼, 계정에 2차 인증을 달아두면 그거 생각보다 효과 있습니다.

아이디와 패스워드를 맞췄다고 해도 이런 창이 뜨거든요. 결국 저거 할려면 휴대폰 있어야 합니다.

휴대폰까지 도둑을 보내서 훔쳤다? 음… 수고요

근데 이건 프로그래밍 방식 접근에서는 효과가 없습니다. 프로그래밍 방식에서는 2FA를 적용할 수가 없거든요.

요약

원래 글은 길면 안읽습니다. 수능 국어 지문도 귀찮은데 이 글이라고 안 귀찮을리가 없죠.

정책은 왠만하면 필요할 때 직접 만들어서 쓰자
권한을 줄 때 Full 이라는 이름이 붙은 것들은 왠만하면 피하자
정책 적용하기 전에 반드시 시뮬레이터를 돌리자
IAM Acesss Key와 Secret Key는 안전한 곳에 잘 보관하자. 이왕이면 서비스 IAM에 주는 걸 권장
2FA는 왠만하면 켜자 (특히 관리자는 반드시 켜도록 하자, 프로그래밍 방식 접근에는 효과 없음)

이렇게 하면 그래도 좀 막을 수 있다고 생각합니다.

클라우드라고 하면 엄청난 보안이 필요할 것 같고 한데 제 개인적인 생각으로는 서비스와 자원에 대한 권한만 적절하게 잘 주면 그래도 2/3은 먹고 들어가는 것 같습니다.

참고

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/introduction.html

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/access_policies_testing-policies.html

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/access_policies_create.html

(도움) https://www.youtube.com/watch?v=pEDsNFetjrU