본문 바로가기
AWS/AWS SAA-CO3

2. IAM, AWS CLI, SDK, CloudShell,

by jys275 2025. 8. 25.

 

 

IAM

 


Identity and Access Management의 약자 : IAM에서는 사용자를 생성하고 그룹에 배치할 수 있음 : 사용자(User), 그룹(Group), 권한(Policy) 을 관리하는 서비스 : IAM은 글로벌 서비스라서 특정 리전에 종속되지 않음 : 어떤 사람이 어떤 서비스에 어느 정도 접근할 수 있는지를 정함

 

우리는 사실 이미 IAM을 사용함 : 계정을 생성할 때 자동으로 루트 계정이 생성됨 : 우리 계정의 루트 사용자가 됨 : 즉, 이 루트 계정도 IAM 체계 안에 포함된 특수한 사용자임 : 그 후에는 루트 계정을 더 이상 사용해서도, 공유해서도 안 됨 : 모든 권한을 가졌기 때문 : 즉, AWS 계정을 설정할 때 제외하고 루트 계정은 사용하지 않고, 새로운 사용자가 AWS를 사용하고 싶어하면 자격증명 정보를 제공하면 절대 안되고, IAM 사용자를 생성해주면 됨

 

그럼 루트 계정은 왜 있고, 어떻게 사용자들을 관리하라는 거? : AWS 계정이 처음 생겼을 때는 루트 계정만 존재 : 따라서 IAM을 처음 설정할 때, 루트 계정으로 로그인 : IAM 관리자를 생성 : 그 관리자에게 AdministratorAccess 권한을 부여 : 이런 식으로 루트 계정을 안 쓰고도 IAM을 관리할 수 있음


그 대신에 IAM 사용자를 생성해서 만들어 쓰는게 일반적 : IAM에서 사용자를 생성할 때 하나의 사용자는 조직 내의 한 사람에 해당됨 : 필요하다면 사용자들을 그룹으로 묶을 수도 있음 : 즉, 실제 운영 시에는 IAM 사용자(조직 내 개인 단위)를 만들어 권한을 부여하고 사용해야함 : 예를 들어, 여섯 명으로 이루어진 조직이 있다고 하자 : Alice, Bob, Charles, David, Edward, Fred

  • Alice, Bob, Charles는 개발자 : Developers라는 그룹을 생성 후 배치
  • David, Edward : Operations 그룹
  • 이제 IAM에는 두 개의 그룹이 있는 것 : 그룹에는 사용자만 배치할 수 있음 : 다른 그룹을 포함시킬 순 없음 : 이게 중요
  • 그룹에 포함되지 않은 사용자? : Fred는 혼자이며 어느 그룹에도 속하지 않음 : 이것도 가능 : 또한 한 사용자가 다수의 그룹에 속할 수도 있음


그러면 사용자와 그룹을 생성하는 이유는 뭐지?

이들이 AWS 계정을 사용하도록 허용하기 위해 : 그리고 허용을 위해서는 이들에게 권한을 부여해야함 : 이를 위해 사용자 또는 그룹에게 정책, 또는 IAM 정책이라고 불리는 JSON 문서를 지정 가능 : 특정 사용자, 혹은 특정 그룹에 속한 모든 사용자들이 어떤 작업에 권한을 가지고 있는지를 지정 가능 : 이와 같은 형태의 JSON 문서를 통해 사용자들이 AWS 서비스를 이용하도록 허용하는 것

새로운 사용자가 너무 많은 서비스를 실행하여 큰 비용이 발생하거나, 보안 문제를 야기할 수 있기 때문 : 따라서 AWS에서는 최소 권한의 원칙을 적용 : 즉 사용자가 꼭 필요로 하는 것 이상의 권한을 주지 않는 것 

 

IAM 사용자 생성

IAM 사용자를 생성하면 어디에서나 사용 가능 : 아무튼 루트 계정을 사용하는 것은 최선이 아님 : 그래서 관리자 사용자와 같은 사용자를 생성하려고 함

위와 같이 IAM > 사용자 탭에서 생성 가능 : 이해하면 좋은게 관리자 사용자 같은 IAM 사용자를 생성하고 싶음 : 콘솔 관리 권한 부여

위와 같이 기존 그룹에 사용자를 추가하고, 직접 정책을 부여하는 등의 옵션이 있는 것을 볼 수 있음 : 일단 초창기니 admin이라는 그룹을 생성할 것 

AdministratorAccess 권한 부여 : 이렇게 하면 admin이라는 그룹에 포함될 추후 사용자들 또한 모두 해당 권한을 동등하게 부여받게 됨

 

IAM 정책

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "1",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:root" },
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::my-bucket"
    }
  ]
}
  • Version : 정책 언어 버전 (보통 "2012-10-17")
  • Statement : 하나 이상의 문장
  • Sid : 문장 ID (선택)
  • Effect : 허용(Allow) or 거부(Deny)
  • Principal : 적용 대상 (사용자, 계정, 역할)
  • Action : 허용/거부할 API 동작
  • Resource : 동작이 적용될 리소스

Effect, Principal, Action, Resource 4가지를 특히 잘 기억해두자 : 만약 *로 내용을 적는다면 모든 권한을 허용하는 것임

 

 

IAM MFA

이렇게 생성한 사용자와 그룹을 보호하기 위해선 비밀번호를 잘 설성하는 것도 있지만 다중 인증 또는 MFA도 존재함 : 그렇다면 MFA란 무엇일까? : MFA는 알고 있는 비밀번호와 내가 소유한 보안 장치의 조합을 사용하는 것 : 두 가지를 함께 사용하여 단순한 비밀번호보다 보안이 훨씬 강화되는 것임 : 따라서 MFA의 이점은 비밀번호를 도난당하거나 해킹당하여 비밀번호를 잊어버린 경우에도 해커가 물리적 장치도확보해야 하므로 계정이 손상되지 않는다는 것


그렇다면 AWS에서 MFA 장치 옵션은 무엇이 있을까? : 시험을 보기 전에 이것들을 알아야 함 

  • 가상 MFA 장치 : 한 번에 하나의 휴대폰에서만 작동하거나 인증을 사용하는 구글 인증기를 사용할 수 있음 : 단일 장치에서 여러 토큰을 지원하는데 : 루트 계정, IAM 사용자, 다른 계정, 다른 IAM 사용자를 가질 수 있음 : 가상 MFA 장치에서 원하는 만큼 많은 사용자와 계정을 보유할 수 있음
  • 유니버설 세컨드 팩터, UTF 보안 키 : 이는 물리적인 장치 : 단일 보안 키를 사용하여 여러 루트 및 IAM 사용자를 지원 : 따라서 사용자 수만큼 많은 키가 필요하지 않음

 

IAM Role

사람이 로그인해서 쓰는 게 아니라 EC2, Lambda, CloudFormation 같은 서비스가 AWS 리소스에 접근할 때 사용 : 즉 사용자용이 아니라 AWS 서비스용 권한임 : AWS 서비스(EC2 인스턴스 등)가 다른 AWS 서비스에 접근하려면 권한이 필요한 것임 : EC2 인스턴스가 IAM에 있는 모든 내용을 읽을 수 있도록 IAMReadOnlyAccess 정책을 연결할 수 있음

 

IAM 보안 도구

  • IAM 자격 증명 보고서 (Credential Report) : 계정 수준에서 생성 가능 : 보고서 내용 : 계정 내 모든 사용자 + 자격 증명 상태(비밀번호, 액세스 키 활성/비활성, MFA 적용 여부 등) : 보안 점검 시 계정 전체를 한눈에 확인할 수 있음 : 이 보고서는 비밀번호를 변경하지 않거나 비밀번호나 계정을 사용하지 않는 사용자들을 확인할 때 매우 유용
  • IAM 액세스 관리자 (Access Analyzer / Access Advisor) : 사용자 수준에서 확인 가능 : 보여주는 것 : 해당 사용자가 어떤 서비스에 권한을 가졌는지 : 마지막으로 그 서비스를 언제 사용했는지 : 활용? : 사용하지 않는 권한을 식별 : 불필요한 권한 제거 : 최소 권한 원칙(Least Privilege) 실현


 

 

AWS CLI

 

 

AWS에 접근하고 사용하는 방법은 콘솔을 사용하는 방법이 있었음 : 하지만 명령줄 인터페이스인 CLI도 있음 : 엑세스 키를 생성해 터미널에서 AWS에 엑세스가 가능 : 이 엑세스 키는 절대로 공유x

https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/getting-started-install.html

 

최신 버전의 AWS CLI 설치 또는 업데이트 - AWS Command Line Interface

이전 버전에서 업데이트하는 경우 unzip 명령을 실행하면 기존 파일을 덮어쓸지 묻는 메시지가 표시됩니다. 스크립트 자동화와 같은 경우에 이러한 프롬프트를 건너뛰려면 unzip에 대한 -u 업데이

docs.aws.amazon.com

심지어 콘솔이 아니라 CLI로 모든 작업을 수행하는 경우도 존재

 

 


 

 

AWS SDK

 

 

AWS 소프트웨어 개발자 키트인 SDK : 애플리케이션 코드 내에서 AWS API를 호출하고자 할 때 사용되는 방식 : 해당 방식도 액세스 키로 보호됨 : SDK는 터미널 내에서 사용하는 것이 아님 : 코딩을 통해 애플리케이션 내에 심어 두어야 하는 것 : 애플리케이션 내에 자체적으로 AWS SDK가 있는 것 : 다양한 프로그래밍 언어를 지원 : JavaScript Python, PHP, .NET, ...

 

 


 

 

AWS CloudShell

 

 

CloudShell은 AWS 클라우드에서 무료로 사용 가능한 터미널같은 개념 : AWS CloudShell은 모든 리전에서 사용할 수 없음 : 특정 리전에서만 사용 가능 : 또한 CloudShell을 실행하면 현재 로그인한 AWS 계정의 자격 증명이 자동으로 사용됨 : 따라서 CLI와 다르게 별도로 Access Key를 설정할 필요 없음 : 여기 내에서 실행되는 명령은 모두 설정된 리전이 기본값 : --region으로 다른 리전 지정 가능 : 또한, 파일 업로드/다운로드 및 글씨 조정 등 환경 설정도 가능 : 재시작해도 유지됨

 

 


 

 

총정리 

 

 

  1. IAM 사용자(User)
    회사 내 실제 한 사람 한 사람과 매핑됨 : AWS Management Console 로그인 비밀번호를 가질 수 있음
  2. IAM 그룹(Group)
    사용자만 포함할 수 있음 : 그룹 안에 그룹은 불가 : 여러 사용자에게 동일한 권한을 한 번에 부여 가능
  3. 정책(Policy)
    JSON 문서 형태로 작성 : 사용자나 그룹, 역할(Role)에 붙여서 권한 부여
  4. IAM 역할(Role)
    실제 사람이 아닌 AWS 서비스(EC2, Lambda, CloudFormation)가 사용 : 서비스가 다른 AWS 리소스에 접근할 수 있도록 권한 위임
  5. 보안 기능
    MFA(다중 인증) 활성화 가능 : 비밀번호 정책 설정 가능 (최소 길이, 복잡도 등)
  6. 액세스 방식
    CLI(Command Line Interface)로 서비스 관리 : SDK(Software Development Kit)로 프로그래밍 언어에서 관리 : 이를 위해 Access Key 발급 가능
  7. 감사 및 보안 점검
    IAM 자격 증명 보고서(Credential Report) : 계정 전체 사용자 상태 점검 : IAM 액세스 어드바이저(Access Advisor) : 사용자 권한 + 실제 사용 여부 확인