자격 증명 및 액세스 관리

AWS에서 권한이 작동하는 방식을 이해하는 것은 내부에서 IAM이 어떻게 작동하는지 이해하는 것을 의미합니다. IAM에서 문제는 영어입니다. 의미가 명백한 단어들이 있지만, 깊이 들여다 보면, 사용하는 사람과 상황에 따라 실제로는 완전히 다른 의미로 사용될 수 있습니다. 사용자, 그룹, 역할 같은 단어는 아주 익숙하게 느껴지고, 무슨 뜻인지 다 안다고 생각하기 쉽지만 IAM의 관점에서 보면 극도로 특수한 의미입니다. 지금부터 차근차근 살펴봅시다. 먼저 사용자의 개념부터 시작하겠습니다 사용자란 무슨 뜻일까요? AWS IAM에서 말하는 사용자란 영구 명명된 운영자입니다. 사람이거나 기계일 수 있습니다. 무엇인지는 중요하지 않습니다. 내 자격 증명은 영구적이며, 강제 순환이 있을 때까지는 명명된 사용자에게 적용됩니다. 이름, 암호, 액세스 키, 보안 키 조합 등 무엇이든 관계없습니다. 이것은 시스템의 명명된 사용자를 위한 내 인증 방법입니다. 알겠습니다. 그룹이란 무엇입니까? 자, 이제 이것은 분명해야 합니다. 그룹은 사용자들의 집합입니다. 그룹은 여러 사용자를 포함할 수 있고, 사용자는 여러 그룹에 속할 수 있습니다. 그러니까 Blaine, 이것이 어려울 거라고 말한 것 같은데요. 역할이란 무엇일까요? 이것은 IAM으로 이해하는 것이 중요한데요, AWS IAM에서 역할은 여러분의 권한이 아니기 때문입니다. 역할은 인증 방법입니다. 사용자는 운영자, 사람 또는 기계일 수 있습니다. 중요한 점은, 영구적인 자격 증명 집합이라는 것입니다. 역할은 운영자입니다, 사람이거나 기계일 수 있습니다. 중요한 점은 역할이 있는 자격 증명이 일시적이라는 것입니다 그래서 어떤 경우든, 우리가 보고 있는 것은 사용자를 위한 운영자를 위한 인증 방법입니다. AWS의 모든 것은 API입니다. 이것은 매우 중요합니다. 또한, API를 실행하기 위해서는 먼저 인증을 한 다음 권한을 부여해야 합니다. 이 역할은 권한이 아닙니다, 단순히 인증입니다. 권한은 모든 경우에 정책 문서라는 별개의 개체에서 발생합니다. 자, 이 정책 문서는 JSON 문서입니다, 영구적인 명명된 사용자 또는 사용자 그룹에 직접 연결하거나 역할에 직접 연결할 수 있습니다. 정책 문서에는 제가 화이트리스트로 설정한 특정 API 또는 API 와일드카드 그룹이 나열되어 있습니까, 아니면 어떤 리소스에 대해 허용합니까? 계정의 모든 리소스에 대한 것입니까? 특정 하위 집합에 대한 것입니까? 특정 조건이 있습니까? 홈 네트워크에 있다면 개인적으로만 정책 문서를 허용할 필요가 있을까요? VPN으로 다이얼했다면 어떻게 됩니까, 아니면 어느 위치에서라도 수락합니까? 하루 중 특정 시간에는 기능을 수행할 수 있는 운영자가 있을 수 있습니다. 이들 모두는 정책 문서의 일부로 요소가 됩니다. 이제 운영자들이 연결된 상태에서 하나의 API가 어떤 프로세스를 거치는 과정을 설명해 보겠습니다. 예를 들어 운영자가 S3 버킷에 객체를 배치하려고 한다고 가정해 보겠습니다. 이것은 API 호출입니다. 이렇게 하려면 API를 실행하고, S3에 객체를 배치하고, 버킷의 이름을 지정하고, 객체의 이름을 지정합니다. 그리고 자격 증명 집합을 제공합니다. 액세스 키 보안 키 또는 콘솔 로그인에 사용하는 사용자 이름 및 암호 등 무엇이든 적용됩니다. 그리고 모두 API 실행문입니다. 이 실행문은 AWS API 엔진에 전달됩니다. IAM 엔진이 수행하는 첫 번째 작업은 해당 자격 증명, 사용자 이름 암호, 액세스 키 보안 키를 살펴보고 이들이 활성 인증 자격 증명인지 검증하고, 영구 운영자인 Blaine인지 확인하는 것입니다. 또는 프로젝트 17의 개발자 역할인지, 또는 사용자 모음 전체가 있을 수 있는 관리자 그룹인지 확인하는 것입니다. 어떤 경우든, 그러한 자격 증명이 승인되고 당신의 주장대로 운영자임이 확인됩니다. 그런 다음 해당 운영자, 사용자, 사용자 그룹 또는 역할과 연결된 정책 문서를 가져옵니다. 그리고 모든 정책 문서를 단일 보기로 평가합니다. 우리는 사용자가 수행한 작업, 이 경우, S3에 객체 PUT이 정책 문서에 의해 승인되는지 확인하려고 합니다. 만약 그렇다면 좋습니다. 그런 다음 API를 실행할 수 있습니다. 자 정책 문서에도 명시적 거부가 있을 수 있습니다. 이는 허용된 문을 재정의합니다. 허용이 없다면 암묵적 거부가 있습니다. 그렇게 되려면 최소한 함수 하나를 화이트리스트로 지정해야 하는데 블랙리스트의 경우, 명시적 거부의 경우, 허용 문이 있다고 해도 상관하지 않습니다. 특정 작업을 영구적으로 막고 싶을 때 사용할 수 있습니다. 예를 들어 프로덕션 환경에서 누군가 자산을 중지하거나 종료할 수 없도록 하고 싶다고 가정해보십시오. 리소스 프로덕션에 대해 중지, EC2 중지, EC2 종료를 거부하는 정책 문서를 생성하고, 유일하게 인스턴스를 중지하도록 허용된 승인받은 시스템 관리자를 제외한 모든 그룹, 모든 사용자 및 모든 역할에 연결할 수 있습니다. 이렇게 하면 실수로 여러분의 프로덕션 환경에 들어가 인스턴스를 종료하기 시작한 개발자가 있는 경우에도 거부 정책이 delete 문과 terminate 문이 실행되지 않도록 거부하므로 아무 것도 종료되지 않습니다. 그사람이 개발자라는게 인정받았다 하더래도 마찬가지입니다. 인증. 권한 부여. 또한 추가적인 문제를 해결하는데 그게 바로 손상된 자격 증명 집합의 경우입니다. 예를 들어 제 개인 계정의 경우, 이유가 무엇이든 암호 관리가 엉망이었습니다. 아이에게 내 랩톱을 사용하게 했더니 바이러스를 다운로드했다거나, 다른 사람이 키 로거를 가지고 내 사용자 이름과 암호를 얻었을 수도 있습니다. 저는 멀티팩터 인증을 사용하지 않습니다. 제 시스템에서 두 가지 경우 모두 일어난 적은 없지만, 그렇다고 가정합시다. 이 경우 어딘가에 있는 어떤 악의적인 해커가 내 관리자 아이디와 암호를 입수해 영구 사용자에게 연결된 모든 정책 문서에 액세스할 수 있습니다. 왕국의 열쇠를 발견한 해커는 "비트코인을 넘기지 않으면 자산을 삭제하겠다"고 말하며 회사에 불쾌한 협박 편지를 보냅니다. 그리고 사실임을 입증하기 위해 실제로 일부를 삭제합니다. 회사는 당황합니다. 이제 어떻게 할까요? 사용자에게 연결된 정책 문서를 사용 중이고 루트 수준의 자격 증명을 사용하지 않는 경우, 어떤 계정이 손상되었는지 알지 못하는 보안 매니저는 단일 작업으로 모든 사용자, 그룹 및 역할로부터 모든 정책 문서를 제거하는 단일 API 문을 실행할 수 있습니다. 이제 비트코인을 받지 못한 해커는 비트코인을 원하기 때문에 더 많은 자산을 삭제하여 위협을 합니다. 이럴 때 API 작업이 어떻게 해결되는지 알아 보겠습니다 해커가 Blaine의 자격 증명으로 S3의 개체를 삭제하라는 API를 제출합니다. 이 API는 IAM 엔진에 의해 평가됩니다, IAM 엔진은 사용자가 Blaine임을 확인합니다. 이것은 올바른 사용자 이름과 암호입니다. 그런 다음 계정에서 삭제된 연결된 정책 문서를 확인합니다. 더 이상 Blaine에 연결되어 있지 않습니다. 즉 Blaine은 어떤 문서도 삭제할 수 없습니다. 하지만 시도는 좋았습니다. 한편, AWS CloudTrail에서 모든 API 작업의 성공 또는 거부 사실은 CloudTrail에 기록되므로, 여러분이 시도한 내용을 기록할 예정입니다. 인증 및 승인. 이 두 가지를 구분할 수 있다면 AWS의 작업에 중요한 권한과 보안을 추가할 수 있습니다.