IAM

IAM : identity and access management.
IAM 이 aws에서만 사용하는 단어가 아니다.

IAM은 무엇을 관리하기 위한 서비스인가? 인증과 권한을 분리하기 위한 것이다. IAM helps you securely control access to AWS resources. 반반책임이다.

우리 서비스 사용자가 누구인지를 관리해준다. 예를 들어 관리자/마스터/리뷰어/학생으로 루카스 권한을 나눠 관리한다. 리소스가 계층 구조를 갖고 접근 방식이 다 다르기 떄문에 어렵다.

root 계정으로 로그인. 루트 계정 하지 말라고???
보안 자격 증명에서 이중 MFA 디바이스 할당 한다. 이 때 주의사항이, 폰을 바꿀 때 반드시 이것을 해지하고 폰을 바꿔야한다. 루트 어카운트는 영어로

그룹을 만들고 policy 를 붙여준다. 예시는 admin 그룹이니까 admin policy를 붙여준다. (root 계정이면 admin policy를 붙일수있다.) 우리는 어드민 사용자를 사용해야하지, 루트 계정 사용을 권장하지 않는다. 유출했을 때 피해를 줄이기 위해서이다. 루트로 어드민을 제어할 수 있기 때문에 어드민 유출시 루트로 제어 가능하다. 그런데 루트 유출되면 어드민으로 어떻게 할 수가 없다.

admin그룹은 admin policy와 관련있다. 인터넷으로 다른 리소스를 사용. 네트워크를 통해 쓰니까 사용하기 위해 api를 호출한다. 모든 aws 버튼 하나는 api동작하나와 연결돼있다. 실제적 동작은 웹api를 통해한다. 옛날엔 soap, ..
http 프로토콜로 원격에 요청하고 명쳥을 받아오는 것을 웹 api라고 한다. action에 * 이므로 모든 api를 쓸수있단 뜻이다. 따라서 이 정책 이름이 administrator access이다.
admin그룹은 admin권한을 갖고있고, 사용자를 하나 만들면 된다.
액세스 유형은 프로그래밍 액세스, aws 매내지먼트 콘솔 둘다 선택한다. (실습 때는 두번째 aws management console만 선택했었다.) 비밀번호는 자동생성, 귀찮으니 비번은 자동생성해제..? 한다.
사용자 그룹에 추가한다.

결제대시보드에 요금을 볼 수 있다. 루트 계정에서 다른 사용자도 요금을 볼수있게 설정해야한다. 만약 요금이 나왔다면, cost explorer에 들어가서 일별 요금으로 바꾸고, 4월1일부터 12일까지 선택해 적용하면 된다. 프리티어 끝나면 요금이 나올수있으므로 .. 첫달이면 아마존한테 구구절절한 눈물의 편지 보내면 봐준다.

IAM 정책 들어가 정책을 선택하면 어떤 권한을 허용하는지 볼 수 있다. NotAction은 이것빼고 권한을 준다는 것이다. 권한이 겹칠수가 있다. 여러 그룹에 속할수도, policy룰이 겹칠수도 있다. 이것들을 전부 정리된 권한이 나의 권한이 된다. 권한이 명시적 allow, deny, implicitly allow, deny가 있다. 모든 aws 권한은 implicitly denie이다. 일단 계정을 만들면 아무것도 쓸수가 없단 것이다. 기본적으로 모든 사용자가 이 상태이고, 여기서 explicitly allow를 해줘서 특정 서비스를 쓸 수 있게 한다. 그런데 explicitly denied는 명시적으로 이 서비스 쓸수없다고 말해주는 것이고, 이것이 앞서 언급한 세개 중 가장 강력한 권한이다. 그렇기 때문에 여러 권한이 겹친다면, 가장 강력한 explicitly denied가 적용되어 권한이 없고 사용할수 없다.

번외로
CloudTrail: AWS의 모든 활동을 추적할 수 있다. 디폴트는 비활성화 상태인데, 실제 서비스에선 무조건 활성화한다. s3를 사용하고, 30기가까지 무료인데??? 텍스트로 30기가 생기기 어려우므로 괜찮을 것이다.
넷플도 aws를 써서 aws에 장애나면 넷플도 장애난다. 데이터센터가 홍수로 잠기거나 폭탄 터지면 장애난다. 아무튼 연말에 넷플 사용자가 가장 많은데 이브에 aws 장애가 났다. 그래도 넷플이 aws가 장애가 날수있던걸 몰랐던 우리 잘못입니다~ 뭐 이래서 넷플이 뒷돈을 찔러줬단 얘기가 있다.
chaos monkey 등이 살아서 돌아다니며 실서비스 되는 것들을 무작위로 죽인다. chaos gorilla는 주기적으로 데이터 센터를 죽인다. aws는 어차피 장애가 날 것, 우리가 만들자는 것이다.
N(exon)에서도 비슷한 걸 만들고, 겁나서 작동은 못하고, ec2에 넣어서 작동하면 깨어나게 했다. 누군가 그걸 깨워서 서버 장애가 났다. 누가 깨웠는지 알려면 cloud trail을 쓰면 누군지 알수있다고 한다. 원래 용도는 어떤 서비스의 어떤 api가 호출됐는지 알 수 있는 거다... 다르게 쓸수도있지만...

사용자에서 권한을 추가하기 위해선, 권한그룹에 추가할수도 있지만, 정책에 직접 연결도 가능하다.
또는, Inline 정책은 직접 json으로 권한을 하드코딩해서 넣는 것도 가능하다. 직접 적용했어도 우선순위는 똑같다. 이 정책은 추가된 사람에게만 고유하게 해당하는 것이고, 다른 사람은 쓸 수 없다. 많이 쓰이진 않는다.

role 자체는 똑같아서 role만들때 이름을 만들고, policy를 붙인다. 그룹이랑 비슷하게 들린다. 차이점은, 그룹엔 사용자만 들어갈 수 있지만, role은 들어갈 수 있는 대상을 지정하지 않고, role사용 대상을 아무나 사용할수있고(예를 들어 ec2에 role부여 가능) 신뢰할수있는 사용자를 지정할수있다. power user에 IAM role부여해서, admin대신에 사용하는 것이 좋은 패턴이다. 어드민 유저 접근 최소화하는 것이 좋다.
aws role은 temporarily credential이라 일시적으로 부여되는데, 작업이 필요할때만 쓰는 임시 자격 부여 서비스를 iam role이라고 한다. 기존의 그룹은 롱 텀 credential이라 계속 유지가 되는 반면 iam role은 short term credential이라 작업할 떄만 쓰이고, 일정 시간 지나면 저절로 만료되어 권한이 사라진다. 세션과 비슷하다. 그렇기 때문에 role이 조금더 안전하다.
람다가 ec2를 쓸 수 있는 권한을 iam role을 이용해 줄 수 있다. 한 aws 서비스가 자신이ㅡ 소스를 관리하는 일이 아주 많다. ec2 람다에 업로드한다. 한서비스가 다른 서비스에 authorization하는 일이 많기 때문에 iam role을 사용한다.
ec2인스턴스에 대해,

내 컴이 aws를 제어할 수 있는것은 액세스 키와 시크릿 키를 통해서다. 이 롱텀크리덴셜을 갖고 내 커미 aws에 접근할 수 있는지 확인해서 하는 것이다. 똑같은 것을 ec2에도 할 수 있다. ec2 인스턴스를 하나 만드는 단계3에 인스턴스세부정보구성에 IAM 역할: role 지정할 수 있다. 이 ec2인스턴스가 사용할 role을 여기 붙일수가 있다. 액세스키와 시크릿 키 관리도 나쁜점이고, 바뀔때마다 ㅓㅂ데이트해줘야하고, 해커가 여기로 들어오면 액세스키시크릿키가 유출되는 문제가 있다. 그래서 ec2도 서비스 일종이기 때문에 iam role을 사용할 수 있는 것이다.
역할 만들기: 신뢰할수있는 유형의 개체를 aws서비스, ec2 선택해서 ec2가 쓸 role이란 것을 선택해준다. 만들어진 role 에 ARN이 있다. amazon resource name이란 게 있고, 이 롤을 유니크하게 식별할 수 있는 식별자가 있다. 이것을 이용해 수동으로 호출할 수도 있다. 아무튼 만들어진 인스턴스로 돌아가 작업-보안-IAM 역할 수정해 role을 attatch해서 수정, 선택할 수 있다. 이 role을 이 instance가 assume하면 s3에 접근할 수 있게 된다.

남의 계정 사용자에게 내 계정 권한을 줄 수도 있다. 어떤 대상에게든 임시로 aws 인스턴스 권한을 부여할 때 role을 사용하면 된다.

aws s3에 저장돼 있다. 안드로이드클라이언트가 플레이할 때 s3 컨텐츠를 다운받아 플레이한다. 만약 aws에 user계정 신규생성하도록 하드코딩하면 아이디 비번을 해킹당할 수 있다. 한시간 반 정도만 해당 컨텐츠를 읽을수있게 권한을 주면 된다.