AWS Section 4-2. IAM 및 AWS CLI

✏️ IAM MFA

---

📌 IAM 계정을 보호하는 방법

 

1. 비밀번호 정책 설정

• 강력한 비밀번호는 계정 보안을 강화
  • 최소 비밀번호 길이, 특정 문자 유형 요구 가능.

비밀번호 정책을 수정할 수 있으며 , 사용자 지정으로 할 수도 있음(비밀번호 최소 길이 강제, 어떠어떠한 문자 요구, 만료 설정 등)

 

2. 다중 인증 (MFA) _ 🌟매우 권장🌟

• MFA는 비밀번호 외에 추가 보안 장치를 사용하는 방식
  • 루트 계정과 IAM 사용자 보호에 필수적.
  • 비밀번호가 도난당하더라도 물리적 장치가 필요하므로 해킹 방지 가능

    

    .

 

🔬 MFA 장치 옵션

---

1. 가상 MFA 장치
   • Google 인증기 등을 사용하여 한 기기에서 다수의 계정 및 사용자 관리 가능.
2. Universal 2nd Factor (U2F) Security Key
   • 물리적 보안 키, 여러 사용자 및 계정 지원.

   

   
   
   • 단일 보안 키를 사용해 여러 루트 및 IAM 사용자를 지원함.
     • 즉 사용자 수만큼 많은 키가 필요하지 않음.
3. Hardware Key Fob MFA Device
   • 물리적 하드웨어 장치, Gemalto 및 SurePassID에서 제공

   • 

     . Gemalto에서 제공하는 하드웨어 보안 토큰 MFA 장치

다중 인증 장치에 대한 엑세스 권한을 잃어버려 계정에서 스스로 lock out된 사람들도 있음.

iPhone 등을 분실할 위험이 있다고 생각되면 우선은 실습 진행 X (나는 직접 실습 X )

 

 

📌 AWS에 접근하는 3가지 방법

---

• AWS Console
  • 사용자 이름, 비밀번호, 다요소 인증(MFA)으로 보호.
  • 그래픽 인터페이스를 통해 AWS 서비스에 접근.
• AWS CLI (Command Line Interface)
  • Access key로 보호.
  • 터미널에서 명령어를 통해 AWS 서비스와 상호작용.
  • 스크립트를 통해 자동화 가능, AWS 공용 API에 직접 접근.
• AWS SDK (Software Development Kit)
  • 애플리케이션 코드 내에서 AWS API를 호출하기 위한 라이브러리 집합.
  • 다양한 프로그래밍 언어 및 플랫폼을 지원하며, Access key로 보호.
  • SDK는 터미널이 아닌 애플리케이션 내부에 통합되어 사용.

💡 Accecc key 생성 방법

• AWS Console에서 생성하며, Access Key ID는 사용자 이름, Secret Access Key는 비밀번호처럼 관리.
• 둘 다 외부에 공유하지 않도록 주의.

• 위 둘이 있으면 CLI에 이들이 적용되면 AWS API에 접근이 가능 !!

📌 CLI (Command Line Interface):

• AWS 서비스와 상호작용할 수 있는 명령줄 도구.
• AWS 서비스의 공용 API에 직접 접근 가능.
• 스크립트를 통해 리소스 관리 작업을 자동화할 수 있음.
• 오픈 소스이며, GitHub에서 소스 코드를 확인할 수 있음.

📌 SDK (Software Development Kit):

• 특정 프로그래밍 언어용 라이브러리 모음.
• 각 언어별로 개별 SDK 제공.
• 애플리케이션 내에서 AWS 서비스를 프로그래밍적으로 접근 가능.
• 다양한 프로그래밍 언어, 모바일 SDK, IoT SDK 지원.
• AWS CLI는 Python용 SDK인 Boto에 기반해 구축됨.

 

 

실습

✔️ 실습_AWS CLI 설치

✔️ 실습_액세스키 만들기

IAM 사용자나 그룹에 필요한 권한을 부여한 상태이므로 명령어를 aws iam list-users 실행하여 IAM 사용자 목록을 조회할 수 있음

 

 

IF ) 사용자로부터 권한을 제거하면 ?

• 이 작업을 수행할 수 있는 권한이 없다는 메세지가 표시됨.
• 마찬가지로 aws iam list-users 명령어를 적어도 위에 처럼 정보를 확인할 수 없음
• >> 즉 CLI 권한은 IAM 콘솔 권한과 완전히 동일하다는 것을 알 수 있음.

 

CLI 의 대안 : Cloud Shell

🙆🏻‍♂️Cloud Shell의 장점🙆🏻‍♂️

• AWS CLI를 사용하는데 필요한 자격 증명이 이미 CloudShell에서 설정된 것처럼 자동으로 처리됨
• >> (즉, 별도의 자격 증명 설정 없이도 바로 사용할 수 있다는 장점)

• Cloud Shell에는 전체 저장소가 있음
  • CloudShell은 영구적인 저장소를 제공하여, 사용자가 만든 파일이 CloudShell 세션을 종료하거나 재시작해도 그대로 유지됨.

  

  
  
  • “test” 단어를 포함한 demo.txt 파일 생성하고
  • Cloud Shell을 Restart해도 파일은 그대로 존재하는 것을 볼 수 있음

 

• 구성이 가능함
• 파일들을 업로드, 다운로드 할 수 있음.

 

 

📌 AWS 서비스에 대한 IAM 역할

---

• 일부 AWS 서비스는 사용자를 대신해 작업을 수행하기 위해 권한이 필요함.
• 이를 위해 IAM 역할을 생성하고, AWS 서비스에 할당함.
• IAM 역할은 실제 사용자가 아닌, AWS 서비스가 사용하는 권한임.
• 예를 들어, EC2 인스턴스는 가상 서버처럼 동작하며, AWS에 접근할 때 IAM 역할을 사용해 필요한 권한을 얻어 작업을 수행

 

 

IAM 보안 도구

• IAM 자격 증명 보고서 (account-level)
  • 계정의 모든 사용자와 다양한 자격 증명의 상태를 포함
• IAM Access Advisor (user-level)
  • 사용자 수준에서 가능
  • Access Advisor는 사용자에게 부여된 서비스 권한과 서비스가 마지막으로 액세스된 시기를 표시함.
  • 이 정보를 사용해 정책을 수정할 수 있음

 

📁 자격 증명 보고서 다운로드 가능

 

• 다양한 정보들을 얻을 수 있음
• 비밀번호를 변경하지 않거나, 비밀번호 계정을 사용하지 않는 사용자들을 확일할 때 유용

 

 

👍🏻 IAM 가이드라인 및 모범 사례 👍🏻

---

• 루트 계정은 계정 설정 시를 제외하고는 사용하지 않음.
• 물리적 사용자 1명당 AWS 사용자 1명을 생성.
• 보안은 그룹 수준에서 관리할 수 있음.
• 강력한 비밀번호 정책을 설정하고, 다중 인증(MFA)으로 보안을 강화.
• AWS 서비스에 권한을 부여할 때는 IAM 역할을 사용하는 것이 바람직함.
• CLI 또는 SDK 사용 시 Access Key를 생성해야 함.
• IAM 자격 증명 보고서나 IAM 액세스 관리자 기능을 활용할 수 있음.
• IAM 사용자 및 액세스 키를 공유하지 않음.

📌 IAM 공동 책임 모델

---

• AWS의 책임 대상, 우리의 책임 대상을 확실히 하기 위함
• AWS는 인프라(글로벌 네트워크 보안, 취약점 분석, 서비스 제공 등)에 대해 책임짐.
• 사용자는 IAM 관리(사용자, 그룹, 역할, 정책 생성 및 관리, MFA 활성화, 키 교체, 권한 부여, 모니터링 등)에 대해 책임을 짐.
  • AWS 인프라 위에서 작동하는 보안 관리는 사용자의 책임임.
  • AWS가 해주지 않는 것들

AWS : 인프라 / 우리 : 인프라를 이용하는 부분을 각각 책임짐

 

 

요약

• Users
  • 실제 사용자와 매핑되어 있으며 AWS 콘솔의 비밀번호가 필요
• Groups
  • 사용자들을 그룹으로 묶을 수 있고 사용자로만 구성 가능
• Policies
  • 사용자 또는 그룹에 대한 권한을 요약한 JSON 문서
• Roles
  • EC2 인스턴스 또는 AWS 서비스를 식별하는 데에 사용되는 역할
• Security
  • MFA + 비밀번호 정책 활용
• AWS CLI
  • command-line을 사용하여 AWS 서비스 관리
• AWS SDK
  • 프로그래밍 언어를 사용하여 AWS 서비스 관리
• Access Keys
  • CLI 또는 SDK를 사용하여 AWS에 액세스
• Audit
  • IAM 사용 감사를 위해 자격 증명 보고서를 만들거나 IAM Access Advisor 서비스 이용 </aside>