클라우드를 시작하는 사람을 위한 안내서

시작하는 사람을 위한 안내서를 작성하고 싶었는데, 좀 늦었다.

매번 하는 말이지만 내 게으름 때문이다.
꼭 누군가에게 도움이 되는 글을 작성하고 싶었는데 그게 바로 오늘인 듯 하다.

클라우드를 하려면 먼저 계정을 생성하여야 한다.

계정을 생성 하였는가? 축하한다. 드디어 클라우드에 입문한 셈이다.

Twitter 上的 DRX|KNEE:"일리단님의 말이 떠오르는 어제 하루였다 아직 준비가 안됐다  https://t.co/QjLPBqUo64" / Twitter

클라우드는 보통 웹 콘솔로 처음 접하게 된다.
CSP 에서 제공하는 웹사이트에 가입을 했다면 뭘 해야 할지 고민이 될 것이다.

모든 설명은 AWS를 기준으로 작성된다.

걱정 마라.

처음 가입하면 뭘해야 할지 바로 알려주겠다.

  1. MFA
  2. Budget
  3. Root 계정 봉인

3가지의 조치가 왜필요한지 이야기해 보겠다.

먼저 MFA를 하지 않아 털리게된다면 공격자는 AWS Console을 편하게 이용할 수 있다. 걸리기 전까지 컴퓨팅을 마음껏 쓸수 있는것이다. 이렇게 털린 계정은 전적으로 사용자 과실이다.

길바닥에 떨어진 지갑은 일반적인 사회라면 경찰서에 가져다주고 주인을 찾아 주겠지만, 그렇지 않은 경우도 많다. 그 길바닥에 떨어진 지갑이 바로 당신의 클라우드 계정이다. 작게는 수백 크게는 수억원까지 비용이 발생할수 있다. 이러한 대 참사를 막기위한 조치이다.

루트계정의 MFA를 설정하여 접근을 막고, 예산을 설정하여 비용이 초과되면 알럿을 받고, 루트계정을 사용하지 않는 방법과 역할 전환을 이용하여 계정의 보안을 강화하는 방법이 가장 적절한 방법인것이다. 여기에 리소스가 생성되면 알림을 받는것도 좋고, 사용하지 않는 태그를 기반으로 리소스가 생성되면 자동으로 삭제하는 방식도 좋다. 이런 여러가지 방식들이 있지만 가장 기본적인 방법이 위에서 제시한 세가지의 방법이다. 그럼 바로 시작하겠다.

MFA

라온클님 역작

MFA를 생성하기 전에 먼저 물어볼것이 있다. 혹시 메일주소가 다른 계정이나, 패스워드가 겹치진 않는가?
이건 굉장히 중요한 문제다. 계정이 다른 아이디 나 패스워드가 겹친다면 삭제하고 처음부터 다시 만들자. 자주사용하는 아이디와 패스워드는 유출될 확률이 높다. 물론 MFA를 사용하면 안전하다. 하지만 언제나 방심하는 순간 문제가 발생한다. 그러니, 콘솔용 메일주소는 별도로 사용하는것이 좋다.

이제 그럼 MFA를 걸어보자.

IAM 서비스로 이동한다 Root 계정의 MFA도 IAM에서 설정할수 있다.

MFA는 사용하지 않으면 IAM 대시보드에 바로 경고가 떠있다. MFA 를 생성하자.

가상 MFA 디바이스를 선택한다.

MFA는 여러 어플이 있는데 나는 MS에서 만든 어플을 선호한다. 온라인백업 기능을 지원한다. QR코드 표시 누르고 그이미지를 백업해두어도 나중에 MFA를 다시추가 가능하다. 하지만 보안이 매우 좋지않음으로 추천하지 않는 방법이다. 보관하려면 압축후 비밀번호를 걸어서 보관하라.

연속된 MFA를 입력하라는건 6자리를 두번 입력해야한다.

두번 입력하면 MFA 설정이 완료된다.

이 쉬운 과정이 일단 그대의 콘솔이 털리는걸 막아주는거다. 로그인이 불편하더라도 꼭 사용하길 바란다.

Budget

Budget 설정은 결제 대시보드에 있다.

예산은 설정하면 알럿이 온다. 예산을 작성하도록 하자.

예산 관련 옵션 들은 FinOps를 위한 여러가지 기능을 제공하는데 우리는 그냥 비용 예산을 작성하면 된다.

일별로 변경후 5$를 설정한다 프리티어에서 하루 5$를 넘으면 대참사다. 한번 만들고 알럿이 귀찮으면 서서히 조정하자.

이메일 수신자에 받고싶은 이메일을 넣어도 되고 SNS 에 주제와, 구독을 생성하여 SMS등으로 받을수도 있으며, Chatbot Alerts를 이용하여 슬랙등 여러 Bot으로 알럿을 받을수 있다. 이메일은 무료고 뒤의 두가지는 비용이 발생할수 있으므로 메일로 받고 관리해야하는 서비스라면 봇이나 SNS를 이용하길 바란다.

이후 예산을 작성하면 이제 일정이상 비용이 넘으면 알럿이 발생한다.

벌써 두가지의 조치를 했다. 남은 두가지만 하면된다.

Root 계정 봉인

Root 계정은 많은 참사를 불러 온다. 이 대 참사를 막기위한 방법이 있다. Root 계정에 MFA를 걸어서 안전하다고 생각할지 모르나, 문제는 언제 어디서 발생할지 모른다. 그렇기에, Root 계정을 봉인하는것을 추천한다.

Root 계정을 사용하지 않고 어떻게 AWS를 안전하게 사용하는지 알려주겠다.

이 방법에는 두가지가 필요하다.

  1. IAM User
  2. IAM Role

먼저 로그인 통로가 될 User를 생성한다. IAM에서 사용자를 추가하면 된다.

IAM 서비스로 이동하고 사용자탭으로 이동해서 사용자 추가를 누른다.

액세스키 방식이 아닌 AWS 관리 콘솔 액세스를 선택한다.

이 계정엔 아무 권한도 주지 않을 것이다.

이렇게 나와야한다. 계정을 생성 완료 했다면 계정의 요약에서 보안 자격 증명을 눌러보자.

콘솔 로그인 링크로 로그인하기 전에 먼저해야할 것이 있다.

MFA다.(궁서체다 매우진지하므로 추가해라.)

MFA는 최대한 활용한다.

이상태가 되면된다. 이제 요약에서 보여주는 콘솔링크로 AWS를 이용한다. 한번 로그인해보시라.

이 아무 권한도 없는 계정은 이제 방파제가 되어 로그인을 제어해줄것이다. 권한이 없는 계정으로 뭘하는지 궁금할것이다. 이때 필요한것이 역할 전환이다. 그럼 IAM Role을 생성하자.

IAM에서 역할탭으로 이동한다. 역할 만들기를 누르자.

다음과 같이 체크해준다.

권한은 여기서 최대 권한을 주지만, 사용자에 맞게 권한을 주는것이 더 적절하다.

역할을 생성하고 이 역할을 사용할수 있도록 수정을 해야한다.

여기서 "arn:aws:iam::00000000000:root" 를 수정해야한다. 수정할 값은 아까만든 계정의 ARN이다. 사용자탭으로 이동해서 계정을 눌러보면

다음과 같이 ARN을 확인할수 있다. 하지만 ARN은 규칙이 있어서 보지않고 그냥 수정해도 된다. 다시 역할로 돌아와서

신뢰관계를 수정하면 이제 생성했던 계정이 이 역할을 사용할수있다. 덤으로 MFA가 활성화 되어야지 만 이 역할을 사용할수 있다.

그럼이제 이 역할을 사용하는 방법은 바로전에 생성한 계정으로 로그인하고, 생성한 역할의 요약 탭에서 보여주는 역할전환 링크를 통해 역할을 전환한다.

다음메뉴에서 역할의 세션지속기간을 설정할수 있다. 역할전환 링크로 이동하면

다음과 같은 화면을 마주하게 되고, 역할 전환을 누르면 이제 IAM 사용자가 역할전환을 이용하여 AdministratorAccess 권한을 승계받은거다. 이제 해커는 MFA를 획득 하더라도 역할전환을 하지 못하면 어떠한 행위도 할 수 없다.

일반적으로 이 방식은 타 계정에서 어카운트를 생성하지 않고 로그인할때 사용하는 방식이다. 혹시 관리계정이 있다면 그관리계정에서 역할전환을 하는것이 더욱 권장되는 방식이다.

이외에도

https://aws.amazon.com/ko/premiumsupport/knowledge-center/config-email-resource-created/

AWS Config 서비스를 이용한 리소스 생성시 추적기능이 있다. 이 부분은 나중에 자세하게 다루어 볼까한다.

SNS EventBridge Config 등의 서비스를 사용하기때문이다.

이 글을 적게된 이유는 최근 여러 커뮤니티를 달군 3억 과금 때문이다. 해킹을 막기 위해선 불편함을 감수해야한다.

편하려다 피눈물 날테니 조심하자.

Linux-stdin-stdout-stderr-2


stderr 는 버퍼를 사용하지 않지만 그것과 별개로 그대로 출력하기 때문에 grep 이 되지 않는것입니다.

https://www.facebook.com/groups/korelnxuser/permalink/2060620130779393/

소용환님께서 답변해주셔서 알 수 있었습니다.

그래서 테스트를 진행하였습니다.

stdbuf 명령어를 이용하여 buffer 를 제거하고 grep 해보았습니다. stdbuf -o0 는 stdout 를 unbuffered 로 출력하는 명력어 입니다.

# cat test.txt 
1
2
3
4
5
6
# stdbuf -o0 cat test.txt | grep 2
2

.

그런데 문득 버퍼사이즈가 0인것과 버퍼가 아주없는 unbuffered 는 차이가 있다는것을 알게되었습니다. 그래서 stderr 에 buffer 를 주었습니다.

# cat test.txt 1>&2 | stdbuf -eL grep 2
1
2
3
4
5
6

# stdbuf -eL cat test.txt 1>&2 | grep 2
1
2
3
4
5
6

.

grep 이 되지 않는것을 확인할수 있었습니다.

이 테스트를 결과로 stderr가 grep 되지 않는것은 buffer의 사용유무와 상관없이 그대로 출력하기 때문임을 알게되었습니다.

https://www.pixelbeat.org/programming/stdio_buffering/

이해를 돕기위해 pixelbeat.org 의 이미지를 첨부합니다.

Linux-stdin-stdout-stderr-1


잘못된 정보를 공유하였습니다.
그부분을 수정하고자 게시물을 다시 올립니다.

바로잡은 내용은 아래의 글입니다.

리눅스에서 stderr 으로 받는 문자열은 grep이 되지 않는다.

이유는 stderr는 Unbufferd 로 출력만 하기때문이다.

# httpd -T | grep http
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 10.0.10.6. Set the 'ServerName' directive globally to suppress this message
(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
AH00015: Unable to open logs

.

위의 경우가 그 예이다.

우리가 사용하는 grep, awk 같은 명령어는 buffer를 이용한다. 그런데 stderr는 buffer 를 거치지 않고 출력하기때문에 grep 나 awk를 사용할수 없는 것이다.

이것을 이해하기 위해선 Buffering을 이해해야 한다.

이런 경우 우리는 2>&1 같은 리디렉션을 이용하여 처리를 한다.

2(stderr)>(리디렉션)&(실행한 다음)1(stdout) 이것은 표준에러를 표준출력으로 변경해준다는 의미로 받아들이면 접근이 굉장히 어렵다. 더 풀어써보겠다.

stderr 는 unbuffer 고 이것을 pipe buffer 를 거쳐 stdin 으로 들어가 grep 은 버퍼내의 데이터를 읽어들여서 stdout로 출력하게 되는것이다.

그냥 버퍼까지 올리지 않던 데이터를 리디렉션으로 버퍼에 넣어준다고 생각하자.

# httpd -T 2>&1 | grep http
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 10.0.10.6. Set the 'ServerName' directive globally to suppress this message

.

다음과 같이 grep 가 동작한다.

grep 는 버퍼를 사용하는 명령어다. 버퍼를 사용하지 않는 출력(stderr)은 grep 할수없다.

버퍼를 사용하는 출력(stdout)는 grep 할수있다.

Mysql-Rows-count

information_schema 스키마는 랜덤샘플링으로 인하여 값의 오차가 생길수 있으므로 정확하지 않음

검증방법

ANALYZE TABLE 테이블명;SELECT table_name, table_rows, round(data_length/(1024*1024),2) as 'DATA_SIZE(MB)', round(index_length/(1024*1024),2) as 'INDEX_SIZE(MB)' FROM information_schema.TABLES WHERE table_schema = '데이터베이스명' GROUP BY table_name ORDER BY data_length DESC LIMIT 10;

ANALYZE 를 진행하며 테이블 확인 - information_schema.TABLES 이 계속 변경되는것이 확인됨

따라서 row count 로 만 검증가능

SELECT     COUNT(*)FROM    테이블명;

대표적으로 자주사용하는 테이블을 카운트하여 비교하는것이 제일 정확

11 x AWS Certification

저는 System Engineer 였습니다.

레거시중의 레거시에 위치한 hosting 을 제공하는 회사에 있었습니다.

하드웨어 서버에 익숙하고, 서버의 자원을 조금이라도 잘쓰기 위해서 여러 방안을 강구하고 매일 테스트했습니다.

자동화 설치를위해서 Clonezilia로 PXE 자동화 설치를 만들고, Hyper-V기반의 DB호스팅을 만들며, 이런저런 오픈소스를 테스트하고, L4, WAF, IPS등 여러 장비들을 다룰줄알고 셋팅도 하였지만, 남들보다 조금 손이 빠른 그저 그런 잡부중 하나일 뿐이었습니다.

그러던 중에 AWS를 만나며, 새로운 세상을 만났습니다. 그동안 힘들었던 서버 설치는 버튼클릭 몇번이면 되고, 비싸서 사용할수 없었던 솔루션, 고객에게 추천하기 어려웠던 구성들까지 그 야말로 세상의 관념이 변하는 느낌을 받았습니다.

그게 2017년이었습니다.

2017년 11월 부터 자격증을 취득하였습니다.

제 시험기록입니다. 10월 21, 2017 - 1월 03, 2022 까지입니다.

59217 번대의 등록번호에서 2163089번대의 등록번호입니다.
200만명을 시험보는동안 11개의 자격증을 취득한것입니다.

시험은 중간에 3번정도 변경되었습니다. Big data / alexa / data analytics 등으로 생기고 없어졌습니다. 지금 Beta에 있는 ERP SAP도 있지만 이건 무시하겠습니다.

시험을 보고 공부하고, 시간이 지나며, 2017년부터 저는 많이 변했습니다.

호스팅업체의 SE에서 지금은 CSP의 SA로 일하고 있습니다.
SE로서 길렀던 능력은 다양한 시스템을 겪고 트러블을 해결하면서 어떤시스템도 어렵지 않게 파악할수 있는 능력이 생겼고, 이 능력을 기반으로 다양한 서비스와 솔루션을 연계하고 옳은 방향으로 비즈니스를 이끌수 있는 방법을 배웠습니다. 그 덕분에 SA로 일할수 있게 되었습니다.

직무를 수행하면서 뿐만아니라 자격증을 공부하고 테스트하면서 간접적으로 느끼고 배운것들까지 저에게 녹아들면서 아키텍팅에대해서 자신감이 붙었습니다.

그러면서 저또한 공부하는 버릇이 붙었고, 그게 저 자신을 만들어갔습니다.

8년차까지 자격증에 대해서 전혀 관심도 없던 저였는데, 어느순간 18개가 넘는 자격증을 취득하게 되었습니다.

자격증은 전문가라는 뜻이 아닙니다. 관심이 있고, 공부를했다는 증명인것입니다. 이것을 업무에 녹이는것은 또 개인의 능력이나, 클라우드 프로바이더의 자격증은 일종의 롤플레잉을 부여하는 방식으로 질문을 던지기 때문에 유사경험이 가능하고, 이것은 나중에 업무를 처리할때 기준을 제시할수 있습니다.

이제 AWS의 11개의 자격증을 모두 취득함으로 소기의 목적을 달성했습니다.

정말 기분이 좋아서 치킨시켜먹었습니다.

정말 쓰고싶은 말이 많았는데, 막상 키보드위에 손을 올리니 정리가 안되네요.

언제든 도움이 필요하신분은 아래 오픈채팅으로 들어오세요.

https://open.kakao.com/o/gMCqYXxb

읽어 주셔서 감사합니다.