당신이 AWS 계정을 만들고 가장 먼저 해야 할 일 들과 하지 말아야 할 일 들 (2022년 업데이트)

 이 글은 tmknom님이 Qiita에 올려주신 'AWS 계정을 만들고 나서 바로 해야 할 일들 정리(AWSアカウントを取得したら速攻でやっておくべき初期設定まとめ)'에서 영감을 받아 작성되었습니다. 처음 AWS 계정을 만들고 나서 무엇을 해야 할 것인가도 중요하지만 하지 말아야 할 것을 아는 것도 중요하기 때문에 해야 할 것들과 하지말아야 할 것들에 대해서 정리해 보았습니다. 전체 과정은 따라하는데 약 30분 정도가 소요됩니다. 아직 계정이 없다면 계정 생성을 먼저 진행해 주세요.

• 아마존 웹 서비스 계정 생성하기 - 44BITS

AWS 계정(루트 사용자) 보호

루트 사용자란?

AWS에 가입할때 맨 처음 만드는 이메일주소와 패스워드로 인증하는 계정을 루트 사용자 라고 합니다. 이 루트 사용자는 그야말로 모든 권한을 지니고 있으며 권한에 대한 제약이 불가능하기 때문에 각별히 신경써서 다루어야 합니다. AWS의 모범사례에 의하면 AWS 루트 사용자를 만든 이후 가장 먼저 해야 할 일은 IAM 계정을 만들고 권한을 부여할 수 있는 IAM 관리자 계정을 만들고 이후 루트 사용자 대신 그 계정을 사용하는 것 입니다. 루트 사용자는 원칙적으로는 평상시엔 사용하지 않는 것이 좋습니다. 혹시 이 글을 읽으시는 분 중에 아직 루트 사용자를 이용하여 작업을 하시는 분이 계시다면 지금 즉시 관리자 권한을 지닌 IAM유저를 만들고 루트 사용자의 사용을 중지하시기 바랍니다.

AWS 루트 계정에 대한 액세스 키를 만들지 말 것

AWS는 패스워드 인증 이외에 CLI나 SDK 사용을 위한 액세스 키 인증을 제공합니다. 하지만 루트 사용자에 대해서 액세스 키를 만들지는 마세요. 이미 있다면 삭제하시고 다른 IAM유저의 액세스 키를 사용해서 작업하시기 바랍니다.

루트 사용자 암호 변경

루트 사용자의 경우 강력한 암호를 사용하시기 바랍니다. 루트 사용자의 암호 변경 방법은 아래 링크에서 확안하실 수 있습니다.

• AWS 계정 ("루트") 암호 변경

루트 사용자에 대해 MFA 활성화

보안을 강화하기 위해 패스워드만 사용한 인증보다는 MFA(Multi-Factor Authentication)을 사용한 인증을 설정해 두세요. AWS에서는 Google Authenticator와 같은 개방형 TOPT 표준을 지원하는 애플리케이션이나 U2F보안키를 MFA에 사용할 수 있습니다. 루트 사용자의 인증에 MFA를 설정하는 방법은 아래 링크를 참고하시기 바랍니다.

• AWS에서 멀티 팩터 인증(MFA) 사용하기
• AWS Multi-Factor Authentication

관리자용 IAM 그룹과 사용자의 작성

관리자용 IAM그룹을 만들고 IAM 사용자를 작성하여 관리자 그룹에 배치시킵니다. 구체적인 방법은 아래 링크를 참고하세요.

• 첫 번째 IAM 관리자 및 그룹 생성

IAM유저 중에서도 관리자 권한과 같은 강력한 권한을 지닌 유저에 대해서는 루트 유저와 마찬가지로 MFA사용이 필수 입니다. 

암호 정책 구성

관리자용 계정으로 로그인 한 후에 암호 정책을 설정하여 IAM 사용자의 암호에 대하여 복잡성 요건과 의무적인 교체주기를 지정할 수 있습니다.

• IAM 사용자의 계정 암호 정책 설정

보안 상태(Security Status)의 확인

여기까지 진행하셨다면 AWS를 안전하게 사용하기 위한 최소한의 조치가 완료되었습니다. IAM 서비스 페이지로 이동하여 대시보드 상에서 보안 권장 사항이 다음과 같이 모두 녹색이 되어 있는것을 확인합니다.

• IAM 서비스 페이지

청구정보 관련 설정

IAM에 대한 설정이 끝났다면 다음은 청구정보에 대한 설정을 진행해 봅시다.

IAM유저의 청구서 정보에 대한 액세스 허가

기본설정에서는 루트 사용자 이외에 유저가 청구정보에 접극하는것이 허가되어 있지 않습니다. 루트 사용자를 가급적 사용하지 않기 위해 IAM유저가 청구서 정보에 접근할 수 있도록 허가해 봅시다.

• 결제 정보 및 도구에 대한 액세스 허용

IAM유저에 대해 결제 정보 액세스를 허용했다면 이후 작업은 관리자 권한을 지닌 IAM유저를 사용해서 진행 할 수 있습니다.

청구정보와 비용 관리에 대한 설정

이메일로 청구서 받기

아래 링크의 지시에 따라 간단한 설정으로 이메일로 청구서를 받아볼 수 있습니다.

• 이메일로 인보이스 받기

프리티어(무료 용량) 한도 초과 경보 

또한 프리티어 한도를 초과할 경우 메일이나 휴대폰 문자(SMS)를 통해 알려주는 결제 경보를 생성할 수도 있습니다.

• 프리티어 결제 경보 만들기

월별 예상 요금 경보 만들기

Amazon CloudWatch를 이용하면 월 초에 사용 용량을 측정하여 월간 예상 AWS 요금에 대해 경보를 받아 볼 수 있습니다.

• 예상 AWS 요금을 모니터링하기 위한 결제 경보 생성

그 밖의 설정들

git-secrets

git-secrets는 AWS가 만들어 공개하고 있는 툴로서 시크릿 액세스키와 같은 비밀 정보가 git에 커밋 되는 것을 막아줍니다.

GitHub에는 이렇게 잘못 올라온 비밀정보를 노리는 봇들이 수없이 동작하고 있어 실수로 정보가 공개되게 되면 악용되게 될 소지가 큽니다.

• git-secrets 페이지

루트 계정 이메일 주소 변경

AWS에서는 여러가지 보안 관련 중요한 사안들에 대해 이메일로 통지되기 때문에 루트 계정의 이메일은 항시 사용 가능한 상태여야 하며 즉시 받아 볼 수 있는 메일 주소여야 합니다. 만약 기존 루트계정을 생성할때 사용했던 이메일을 변경하고 싶다면 아래 지침대로 이메일을 변경하시기 바랍니다.

• AWS 루트 계정 이메일 변경

끝으로

이것으로 일단 가장 기본적인 보안 및 비용 관련 설정이 끝났습니다.

추가적으로는 아래 IAM 모범 사례의 내용을 살펴보고 적용시킴으로서 더욱 강력한 보안을 확보 할 수 있습니다. 몇가지는 이 글과 겹치는 부분도 있지만 상세한 내용을 읽고 확인해 두는것도 좋을듯 합니다.

• IAM 모범 사례

클라우드 잔혹사 - 사고로 살펴보는 클라우드 컴퓨팅의 흑역사

요즘은 어딜가나 IT 관련 스타트업 성공에 클라우드 컴퓨팅의 이야기를 빼 놓을 수 없다. 이러한 성공사례는 각 클라우드 서비스 제공사에서 친절하게 설명하고 있으므로 굳이 여기서 소개하지는 않겠다.

각사의 클라우드 성공 사례 소개 페이지

• SaaS Salesforce 
• PasS Microsoft Azure 
• IaaS Amazon AWS

오늘의 주제는 제목에서 쉽게 짐작 할 수 있겠지만 클라우드 컴퓨팅의 어두운면을 살펴 보고자 한다.

이미지 출처 : linkedin

 바로 얼마전인 6월 17일, AWS를 이용해 코드 호스팅 서비스를 제공하는 직원 여섯명의 영국 벤처기업인 Code Spaces는 DDos공격에 직면한다. 그리고 뻔한 이야기 이지만 이 공격을 멈추고 싶다면 거금을 지불하라는 협박 메일도 받게된다.

 당연히 Code Spaces측에서는 이 협박에 응할 생각이 없었고, 대책을 세우기 위해 AWS의 설정을 변경하려 했다. 하지만, 이미 해커는 Code Spaces의 AWS계정 패스워드를 확보해 놓은 상태였으며 곧 패스워드를 바꿔 제어권을 완전히 가져가 버린다. 황급히 Code Spaces가 아마존에 연락하여 제어권을 되찾아 왔을 즈음에는 이미 해커가 모든 데이터와 기기설정, EBS를 이용한 백업, 스냅샷등 AWS상에서 관리되던 모든 자원을 지워버린 이후였다.

사고 이후 Code Spaces의 홈페이지
아마도 인터넷을 이용한 서비스기업에서 생각할 수 있는 최악의 경우에 해당할 것이다. 작은 스타트업이라 해도 해커는 봐 주는 법이 없고, 오히려 보안에 허술하다는 점을 이용해 집중적인 타겟이 되기 쉽다. 

 사내에 물리서버를 두고 운영했다면 이러한 사태를 막을수 있었을까? 물론 이러한 종류의 보안 사고는 클라우드사용이 근본적인 원인이라고 보긴 어려운 측면이 있다.  다만, 여기서 다음과 같은 클라우드 보안과 관련한 몇가지 사항을 짚고 넘어 갈 필요가 있다.

보안주권의 상실

 클라우드 사용에 있어서 가장 민감하면서 까다로운 부분은 보안정책이 사용하는 클라우드 서비스에 귀속되어 버린다는 점 이다. 클라우드 서비스를 사용하는 이상 네트워크 및 하드웨어에 관련한 사항들에 대해서는 일체의 권한이 서비스 제공자에게 종속되어 버린다. 물론 그만큼 편해지자고 하는거지만 파이어월같은 보안 장비도 클라우드서비스의 일부로 의존하게 되는만큼 무조건 믿고 맡겨 보자는 식의 태도는 대단히 위험하다.

 모든종류의 공격 시도에 대해서 파이어월은 외부와의 관문으로서 중요한 단서를 제공하는  장소이다. 하지만 필자가 아는 한 아마존은 보안상의 이유로 공식적으로든 비공식적으로든 파이어월에 대한 로그를 일체 제공하지 않고 있다. 아마존 입장에서는 당연한 이야기 일 수도 있겠지만, 네트워크를 공유하게 되는 클라우드 서비스의 성격상 그 파이어월은 당신의 서비스 만을 위한것이 아니기 때문이다.

 보안관련 이슈 전문 블로거인 Bruce Schneier씨는 2013년 열린 QCon New York의 기조연설에서 봉건적 보안세상에서 살아남기라는 타이틀로 이 문제에 대해 지적했는데, 클라우드 컴퓨팅을 사용할때엔 소프트웨어 파이어월등을 통해 최소한의 스스로의 몸을 지킬 수단은 마련 할 수 있어야 한다고 조언한다.

종속성의 함정

클라우드 컴퓨팅의 도입을 고려할때 또 한가지 고려해야 할 점은, 어떤 클라우드 서비스 업자든 결국에는 자신들의 서비스에 의존성이 생기도록 하는 여러 장치들을 마련해 두고 있다는 점 이다. 이른바 원숭이 꽃신 전략이라고 하는 것인데, 일단 의존성이 생기게 되면 만에 하나 해당 클라우드 업체에 문제가 생길경우 상당히 곤란한 상황에 처하게 된다.

예를 들면 갑작스러운 클라우드 업체의 폐업같은거 말이다.

Cloud Storage Provider Nirvanix Shutting Down

Nirvanix는 폐업을 선언하기 전까지 7년 넘게 클라우드 스토리지 사업을 진행해 오고 있었지만 이메일을 통해 다른곳으로 데이터를 이전하라고 하면서 준 기간은 고작 2주에 불과했다. 클라우드 서비스 사업은 앞으로도 빠르게 성장해 나가는 추세이지만 박리다매에 기반한 비즈니스모델이라는 점 에서 업계 탑클래스 이외의 곳을 선택하는것은 큰 위험이 따른다는 점에 주의를 기울여야 한다.

그러나 업계 탑클래스의 기업이라고 해서 100% 안전한것도 아니다.

Dropbox gets hacked ... again

위 기사에 따르면 2011년 자사직원의 실수로 발생한 보안사고로 인해 네시간동안 드롭박스의 인증체계가 무력화 되었었다 하는데 더 큰 문제는 사용자 입장에서 정말로 네시간만 그런일이 발생했는지, 또 이에 따라 발생된 피해는 어떤것이 있는지에 대해 조사할 방법이 전무하다는 점 이다.

여기에 아마존, 마이크로소프트, 구글등의 미국 국적 회사들은 기본적으로 애국자법이라 불리우는 테러대책법(Anti-terrorism legislation)으로부터 자유로울 수 없다는 점 또한 잊지말자. 물리적으로 서버가 해외에 있거나 해외법인이라 할 지라도 본사가 미국인 이상 모두 이 법의 적용을 받는다. (AWS동경 리전도 마찬가지이다) 테러와 관련이 있다고 미국 정부가 판단하는 사안에 대해서는 클라우드 서비스 내에 들어 있는 데이터에 대해 무제한적인 억세스 권한을 지니며 통지의 의무도 없기 때문에 들여다 봤는지 조차 사용자 입장에서는 알 방도가 없다.
참고로 애국자법은 2011년 오바마 대통령이 법안의 연장에 서명한 덕분에 2015년까지도 유효 하다.

구더기 무서워서 장 못담그랴

 이러한 여러 문제점에도 불구하고 클라우드 컴퓨팅은 분명히 매력적이다. 필자는 20년 넘게 IT업계에서 벌어지고 있는 개척시대의 풍경을 보아오고 있지만 최근 수년간 클라우드 컴퓨팅이 가져오는 변화는 그 20년의 세월동안 보아온것들 중에서도 단연코 놀라운것이다.

 클라우드 컴퓨팅은 개인이 가진 아이디어와 기술이 자본으로부터 자유롭게 날개를 펼칠 수 있는 기틀을 제공해 주고 있다.

하지만, 이러한 클라우드 컴퓨팅이라 할지라도 위험에 대해서 알고 사용하느냐 모르고 사용하느냐는 큰 차이를 가져온다. 세계 최고의 회사가 제공하는 서비스이니 당연히 좋겠지라는 막연한 생각만으로 서비스를 이용하다가는 언젠가 세계 최고의 변호사와 상대해야 할 지도 모르는 일이다.

마지막으로 당신의 안전한 클라우드 컴퓨팅을 위해 다음의 사항을을 고려해 볼 것을 제안한다.

• 오프라인 백업 전략 수립: 해커가 모든 패스워드를 알고 접근루트를 확보한 상태라 할지라도 절대 접근할 수 없는 오프라인의 백업 스토리지를 가져야 한다. 명심하라! 명백한 서비스 제공자의 실책에 의한 데이터 손실이라 할 지라도 클라우드 서비스 제공자는 고작 월 사용료의 10%정도의 보상금(AWS의 경우)을 지급할 뿐이다.
• 자체 보안 정책 수립 및 모니터링: 클라우드 서비스회사는 다양한 보안 옵션을 제공한다. 이를 살펴보고 자신의 서비스를 위한 솔루션을 찾아보자. 침입자에대한 감시와 경고 또한 마찬가지이다. AWS를 사용한다고 하면 멀티팩터인증MFA정도는 반드시 사용하도록 하자.
• 클라우드 서비스 회사의 서포트 담당자와 친하게 지내자: 아직 이 바닥은 좁다. 고객을 직접 상대하는 클라우드 서비스의 고객 담당자는 자사 및 클라우드 업계의 여러 정보에 정통한 고급 정보원이기도 하다. 어설프게 갑질하려 들지 말고 이들과 정기적으로 연락하며 신뢰관계를 쌓아놓도록 하자. 말 한마디에 천냥 빚도 갚는다는 말은 그냥 나온 이야기가 아니다. 필자의 경험상 어떠한 고가의 외부 보안 컨설팅 보다도 이들의 조언은 큰 가치를 지닌다.

보안의 세계에서 이정도면 충분하다는 없다. 당신의 시스템을 노리는 해커는 높은 동기부여를 지니고 창의적으로 일하며 밥도 안먹고 잠도 안자고 일 할 정도로 근면하다. 늘 변화하는 보안관련 트렌드를 파악하고 당신의 서비스에 적용하려는 노력이 없다면 언제든지 당신의 시스템도 뜻하지 않은 재앙에 직면할 수 있다는 점을 명심하길 바란다. 보안에 대한 첫번째 이자 가장 중요한 투자는 끊임없는 공부이다.