tip. 보안에 관해 이야기할 때 보안 시스탬을 이야기 하기보다 약한 부분을 어떻게 보안을 강화했는지 이야기합니다. 보안 시스템의 테크니컬한 부분은 시스템의 능력이지 엔지니어의 능력이라고 보기 어렵습니다. 따라서 애플리케이션에서 보안이 약한 부분을 어떤 방향으로 개선했다는 방향으로 이야기 하는것이 바람직합니다.

심층 방어

심층 방어는 다중 보안 계층을 만드는 데 중점을 둔 전략입니다.

다중 보안 제어를 포함하는 심층 방어 접근 방식을 모든 계층에 적용합니다.예를 들어 네트워크 엣지,  VPC, 로드 밸런싱과 모든 인스턴스, 컴퓨팅 서비스, 운영체제, 애플리케이션, 코드에 심층 방어를 적용해야 합니다. 애플리케이션 보안 또한 인스턴스 보안 못지않게 중요하기 때문입니다.

위 예시에서 여러 사용자가 S3 버킷의 문서를 액세스를 시도합니다. 각 사용자가  AWS에 액세스하기 위해 수임하는 사용자 또는 역할에 자격 증명 기반 정책이 배정되어야 합니다. 해당 정책이 배정되면 리소스 기반 정책 계층이 차례로 적용됩니다. 사용자는 이러한 방식으로 태스크에 필요한 문서를 액세스할 수 있습니다.

자세한 설명

IAM 권한 경계

AWS에서는 IAM의 권한 경계를 지원합니다. 권한 경계는 관리형 정책을 고려하여 자격 증명 기반 정책이  IAM 엔터티에 부여할 수 있는 최대 권한을 설정하는 고급 기능입니다. 권한 경계는 필터 역할을 합니다.

엔터티의 권한 경계에 따라 엔터티는 자격 증명 기반 정책 기반 정책 및 관련 권한 경계 모두에서 모두 허용하는 작업만 수행하도록 허용합니다.

위에서 볼 수 있듯이 권한 경계를 사용하면 IAM 엔터티의 액세스 권한을 보다 세밀하게 제어할 수 있습니다. 위 그림을 예를 들어, IAM 엔터티에 특정 리소스에 대한 액세스 권한을 부여하는 정책이 있다고 가정합니다. 이 정책은 IAM 엔터티가 해당 리소스에 대한 모든 작업을 수행할 수 있도록 허용합니다. 그러나 권한 경계를 사용하여 IAM 엔터티가 해당 리소스에 대한 특정 작업을 수행하는 것을 허용하지 않을 수 있습니다.

이 기능은 특정 리소스에 대한 액세스 권한을 부여하되 특정 작업, 시간, 위치를 제한해 좀 더 새밀한 권한 조정을 위해 사용됩니다.

자세한 내용

다중 계정

조직에서 AWS 사용 범위가 확대되면 다음과 같은 이유로  다중 계정 구조를 생성해야 할 수 있습니다. (보통 조직의 크기가 커지면 커질수록 다중 계정 사용은 필수화 된다고 합니다.)

• 분류 및 검색을 위해 리소스를 그룹화
• 논리적 경계를 통해 보안 태세를 개선
• 무단 액세스가 발생할 경우 잠재적 영향을 제한
• 다양한 환경에 대한 사용자 액세스를 간편하게 관리

AWS Organuzations

상황 1. 미사용

IAM 정책은 단일 계정의 개별 보안 주체에만 적용됩니다. 또한, 제한을 적용하는 정책은 각 계정 내에서 관리를 해야합니다. 때문에 청구서 또한 여러개를 생성해야 합니다. 소규모에서는 상관이 없을 수 있으나 조직이 점점 커진다면 관리가 점점 힘들어질 것입니다.

상황 2. 사용

Organizations를 통해 계정을 조직 단위(OU)로 그룹화하여 계층 구조를 생성합니다. 서비스 제어 정책(SCP)를 통해 OU에 속한 모든 계정의 최대 권한을 제어합니다. 이런 구조를 통해 다음과 같은 이점을 얻을 수 있습니다.

• 모든 AWS 계정을 중앙에서 관리
• 모든 구성원 계정의 요금 통합 결제
• 예산, 보안 또는 규정 준수 요구 충족을 위해 계정을 계층적으로 그룹화
• 각 계정이 액세스할 수 있는 API 작업과 AWS 서비스를 중앙에서 제어 가능
• 조직 계정 내 리소스의 자동 백업을 구성 가능
• IAM 통합 및 지원
• 다른 AWS 서비스와 통합
• 전 세계에서 액세스 가능
• 최종적으로 일관된 데이터 복제
• 무료

자세한 설명

SCP

SCP는 조직의 권한을 관라히는 데 사용할 수 있는 조직 정책 유형입니다. SCP의 특징은 다음과 같습니다.

• 조직의 모든 계정에 사용 가능한 최대 권한을 중앙에서 제어합니다.
• 계정이 조직의 액세스 제어 지침을 준수하도록 보장하는 데 도움이 됩니다.
• 모든 기능이 활성화된 조직에서만 사용할 수 있습니다.

만약 조직이 통합 과금 기능만 지원한다면 SCP를 사용할 수 없습니다.

Organizations 엔터티(root, OU, 계정)에 SCP를 연결하면 가드레일이 정의됩니다. SCP는 해당 계정의 IAM 사용자와 역할이 수행할 수 있는 작업에 대한 제한을 설정합니다. 권한을 부여하려면 조직 계정 내의 리소스나 IAM 사용자에게 리소스 기반 정책 또는 자격 증명 기반 정책을 연결해야 합니다. IAM 사용자나 역할이 속한 계정이 조직의 멤버라면  SCP는 해당 사용자나 역할의 유효 권한을 제한합니다.

IAM 정책과 SCP의 상호 작용 방식

위에서 볼 수 있듯이 두 정책 유형에서 모두 명시적으로 허용되어야 액세스가 가능해집니다. 반대로 한쪽에서만 허용된 S3와 IAM 작업은 허용되지 않습니다.

SCP 자세한 내용

정책을 통한 계층형 방어

보안 주체는 콘솔, AWS API 또는 AWS CLI를 사용하려고 할 때 AWS에 요청을 보냅니다. AWS에서는 여러 리소스를 구성하여 요청 권한을 허용할지 아니면 거부할지를 결정할 수 있습니다.

 IAM 엔터티(사용자 or 역할)는 권한 경계에 따라 자격 증명 기반 정책과 권한 경계에서 모두 허용하는 작업만 수행할 수 있습니다. 이 방식을 사용하는 경우 해당 엔터티에 대해 지나치게 높은 수준의 권한이 필요한 작업을 허용하는 IAM 자격 증명 기반 정책 생성을 방지하는 계층이 추가됩니다.

이 또한 최소 권한 원칙을 준수하기 위한 방법입니다. 보안 파트는 여기서 마무리 되었습니다. AWS 아키택트에서 강조되는 부분이 제일 앞에 왔다고 하는데 AWS에서 보안 부분을 정말 중요시 하는 것 같습니다. 특히 최소 권한을 통한 보안이 과장 조금 보태서 페이지마다 나올 정도입니다.

다음은 AWS 네트워킹에 대해 다루겠습니다.

보안 정책 범주

정책은 자격 증명이나 리소스에 연결되어 해당 권한을 정의합니다. AWS는 사용자와 같은 보안 주체가 요청할 때 이런 정책을 평가합니다.

IAM 권한 경계 및 AWS Organizations 서비스 제어 정책(SCP)을 활용하여 계정에서 수행하는 작업에 대한 최대 권한을 설정할 수 있습니다. IAM 자격 증명 기반 정책과 리소스 기반 정책은 계정에서 수행하는 작업을 허용하거나 거부할 권한을 부여합니다.

AWS에서 사용 가능한 정책은 다음과 같으며 사용 빈도 순으로 나열되어 있습니다.

1. 자격 증명 기반 정책
   IAM 자격 증명에 관리형 정책과 인라인 정책을 연결합니다. 이러한 자격 증명에는 사용자, 사용자가 속한 그룹 및 역할이 포함됩니다.
   
   
2. 리소스 기반 정책
   리소스에 인라인 정책을 연결합니다. 리소스 기반 정책의 가장 일반적인 예는 S3 버킷 정책 및  IAM 역할 신뢰 정책입니다.
   
   
3. AWS Organizations SCP
   Organizations SCP를 사용해 조직 또는 조직 단위(OU)의 계정 구성원에 대한 최대 권한을 정의합니다.
   
   
4. IAM 권한 경계
   AWS에서는 IAM 엔터티의 권한 경계를 지원합니다. IAM 권한 경계를 사용하여 IAM 엔터티가 수행할 수 있는 최대 권한을 설정합니다.

자격 증명 기반 정책

자격 증명 기반 정책은 다음 항목을 제어하는 JSON 권한 정책 문서입니다.

• IAM 자격 증명(사용자, 사용자 그룹 및 역할)dl tngodgkf tn dLTsms wkrdjq
• IAM 자격 증명이 이러한 작업을 수행할 수 있는 리소스
• IAM 자격 증명이 이러한 작업을 수행할 수 있는 조건

자격 증명 기반 정책 유형

• 관리형 정책
  AWS 계정의 여러 사용자, 그룹 및 역할에 연결할 수 있는 독립 실행형 자격 증명 기반 정책으로, 두 가지 유형의 관리형 정책이 있습니다.
  1. AWS 관리형 정책
     AWS에서 생성하고 관리하는 관리형 정책입니다. 특정 서비스 액세스 또는 작업 기능에 대한 권한을 제공하도록 구축되었습니다.
  2. 고객 관리형 정책
     고객이 AWs 계정에서 생성하고 관리하는 관리형 정책입니다. 고객 관리형 정책은 AWs 관리형 정책보다 더 정밀하게 정책을 제어합니다.
• 인라인 정책
  단일 사용자, 그룹 또는 역할에 직접 추가하는 정책입니다. 인라인 정책은 정책과 엔터티 간에 엄격한 일대일 관계를 유지합니다. 즉, 자격 증명을 삭제하면 인라인도 삭제됩니다.
  
  인라인 정책은 사용자가 생성하여 IAM 그룹, 사용자 또는 역할에 직접 포함하는 정책입니다. 인라인 정책은 다른 자격 증명에 재사용하거나 해당 정책이 존재하는 자격 증명 외부에서 관리할 수 없습니다.

고객 관리형 정책 자세한 내용(IAM 보안 모범 사례)

자격 증명 기반 정책 예제

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:AttachVolume",
                "ec2:DetachVolume"
            ],
            "Resource": [
                "arn:aws:ec2:*:*:volume/*",
                "arn:aws:ec2:*:*:instance/*"
            ],
            "Condition": {
                "ArnEquals": {"ec2:SourceInstanceARN": "arn:aws:ec2:*:*:instance/instance-id"}
            }
        }
    ]
}

• Version
  정책을 처리하는 데 사용할 언어 구문 규칙을 지정합니다. 사용 가능한 모든 정책 기능을 사용하려면 정책 버전에 위와 같이 2012-10-17 값을 삽입해줍니다.
• Effect
  Allow 또는 Deny를 사용해 정책이 액세스를 허용할지 거부할지를 지정해줄 수 있습니다.
• Action(또는 NotAction)
  정책이 허용하거나 거부하는 작업 목록을 포함합니다.
• Resource(또는 NotResource)
  작업이 적용되는 리소스 목록을 지정해야 합니다.
• Condition(또는 NotCondition)
  정책이 권한을 부여하는 상황을 지정합니다.

예를들어 IAM 사용자에게 예제 정책 스테이트먼트를 연결할 수 있습니다. 그러면 조컨 충족 시 해당 사용자가 계정에서 EC2 인스턴스를 중지 및 시작할 수 있습니다. 여기서 IAM 사용자가 제어할 수 있는 EC2 인스턴스에는 키가 Owner이며 값은 IAM 사용자 이름과 같은 태그가 있어야 합니다.

• 와일드 카드(*)
  와일드카드는 여러 리소스나 작업에 정책 요소를 적용하는 데 사용됩니다. 이 정책은 모든 계정 번호의 리소스, 그리고 모든 리소스 ID의 리전에 적용됩니다. 그러므로 AWs 계정 ID를 추가하여 정책을 다시 작성하지 않고도 여러 계정에 정책을 재사용할 수 있습니다.

리소스 기반 정책

리소스 기반 정책은 S3 버킷 등의 리소스에 연결되는 JSON 정책 문서입니다. 이러한 정책은 해당 리소스에서 특정 작업을 수행할 수 있는 권한을 보안 주체에 부여하고 이러한 권한이 적용되는 조건읠 정의합니다. 리소스 기반 정책은 인라인 정책이며, 관리형 리소스 기반 정책은 없습니다.

이러한 정책들은 기존 AWS 정책을 사용할 수도 있고, 자신에게 맞게 자체적으로 생성할 수도 있습니다.

리소스 기반 정책 예시

{
   "Version":"2012-10-17",
   "Statement":[
     {
       "Sid":"PolicyForAllowUploadWithACL",
       "Effect":"Allow",
       "Principal":{"AWS":"111122223333"},
       "Action":"s3:PutObject",
       "Resource":"arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
       "Condition": {
         "StringEquals": {"s3:x-amz-acl":"bucket-owner-full-control"}
       }
     }
   ]
}

리소스 기반 정책은 S3 버킷이나 AWS Lambda 함수 등의 단일 리소스에 연결됩니다. 리소스 기반 정책 사용 시에는 리소스에 액세스할 수 있는 사용자와 해당 사용자가 리소스에 대해 수행할 수 있는 작업을 선택합니다.

리소스 기반 정책을 생성하는 경우에는 Principal를 정의해줘야 합니다. 즉, 액세스를 허용하거나 거부할 계정, 사용자, 역할 또는 페더레이션 사용자를 지정하는 것입니다. 이전에 사용자나 역할에 연결할 IAM 권한 정책을 생성했을 때에는 이 요소를 포함하지 않았었습니다. 그 이유는 해당 사용자나 역할이 암시적으로 보안 주체로 적용되기 때문입니다.

또 다른 점은 리소스 기반 정책에서 Resource 요소는 선택 사항입니다. 이 요소를 포함하지 않으면 작업이 적용되는 리소스가 정책이 연결된 리소스입니다.

위 예제에서 Principal은 AWS 계정의 고유 번호입니다. 여기서 리소스는 DOC-EXAMPLE-BUCKET에 있는 모든 객체를 지정해 주었습니다. 이 버킷 정책을 적용하면 특정 AWS 계정이 버킷 폴더에 객체를 업로드할 수 있습니다.

명시적 허용과 명시적 거부

IAM 정책에는 명시적 허용문이나 명시적 거부문 중 하나가 포함되거나 두 문장이 모두 포함됩니다.

1. 명시적 허용 - 명시적 허용은 IAM 사용자, 그룹, 역할이 리소스 집합을 대상으로 나열된 작업을 수행할 권한을 부여하는 것입니다.
   
   
2. 명시적 거부 - 명시적 거부는 IAM 사용자, 그룹, 역할이 리소스 집합을 대상으로 나열된 작업 수행을 시도하면 해당 작업을 중지합니다.

IAM 정책 평가 로직

계정용 IAM 정책을 작성할 때는 AWs 평가 로직을 파악하는 것이 중요합니다. 그래야 사용자와 앱에 필요한 액세스 권한만 제공할 수 있습니다.(최소 권한 원칙)

AWS는 요청 컨텍스트에 해당되는 모든 정책을 평가합니다. 단일 계정 내에서 정책에 사용 가능한 AWS 평가 관련 요약 내용은 다음과 같습니다.

• 기본적으로 모든 요청은 암시적으로 거부됩니다. 단, 모든 액세스를 보유한 AWS 계정 루트 사용자는 예외입니다.
• 자격 증명 기반 정책이나 리소스 기반 정책의 명시적 허용은 이러한 기본값을 재정의 합니다.
• 모든 정책의 명시적 거부는 모든 허용을 재정의합니다. 따라서 안전 조치로 활용하기 좋습니다.

"모든 정책의 명시적 거부는 모든 허용을 재정의합니다"라는 문장은 다음과 같은 예시로 설명할 수 있습니다. 사용자에게 리소스에 대한 액세스를 허용하는 정책이 하나 있고, 사용자에게 리소스에 대한 액세스를 거부하는 정책이 하나 있으면 사용자는 리소스에 액세스할 수 없습니다. 명시적인 거부는 모든 허용을 재정의하기 때문입니다. 즉, 명시적 거부가 명시적 허용보다 우선순위가 높다는 뜻입니다.

자격 증명 기반 정책 및 리소스 기반 정책의 자세한 내용

IAM 사용자 그룹

IAM 사용자 그룹은 이름에서 알 수 있듯이 사용자들을 모아 놓은 그룹입니다. 기존에 사용자에게 권한을 주기 위해 계정에 각각 지정해줘야 합니다. 하지만 수백 수천 명의 사용자가 존재한다면 어떨까요?

좀 더 손쉬운 관리를 위해 그룹에 권한을 지정해주고 사용자를 그룹에 넣으면 해당 사용자는 그룹의 권한을 사용할 수 있게 제작된 서비스입니다.

자세한 내용

IAM 역할

IAM 역할은 임시 AWS 자격 증명에서 제공하는 서비스입니다. 여러 직원과 애플리케이션이 같은 역할을 사용할 수 있기 때문에 관리가 용이합니다. 역할 사용에는 요금이 따로 발생하지 않습니다. IAM 역할은 AssumeRole API를 통해 전달이 되는데 이는 역할 수임 부분에서 자세하게 알아보겠습니다.

예를 들어 위 그림과 같이 DevOps 팀에서 분석을 위한 앱을 사용해야 한다고 가정해봅시다. 분석앱을 사용하기 위해서는 해당 권한이 있어야 합니다. 이 때 직접 권한을 부여하는 것이 아닌 임시로 IAM 역할을 만들어 담당자에게 부여해주는 것입니다. 이렇게 IAM 사용자 그룹에 권한을 주지 않고 담당자에게만 분석앱을 활용할 수 있는 권한을 부여할 수 있게 됩니다.

IAM 역할을 사용하는 방법의 예는 다음과 같습니다.

1. 교차 계정 액세스 - 다른 팀의 사용자가 해당 팀의 권한이 필요할 때
2. 임시 계정 액세스 - 계약자에게 해당 팀의 권한을 임시로 줘야할 때
3. 최소 권한 - 사용자가 IAM 역할을 사용해 원하는 작업을 요구할 수 있습니다.
4. 감사 - 관리자가 IAM 역할을 사용한 사람을 추적할 수 있습니다.
5. AWS 서비스 액세스 - Amazon Lex에서 Amazon Polly를 사용해 봇의 음성 응답을 합성할 수 있습니다.
6. Amazon EC2용 IAM 역할 - Amazon EC2에서 실행되는 애플리케이션이 사용하고자 하는 서비스를 액세스할 수 있습니다.
7. SAML 페더레이션 - 관리자가 외부 IdP에 저장된 자격 증명에 IAM을 사용할 수 있습니다.

역할 수임(Assuming a role, 수임=임무나 위임을 받다)

IAM 사용자, AWS 서비스 또는 페더레이션 사용자와 같은 신뢰할 수 있는 엔터티를 사용하여 역할을 수임합니다.

IAM 사용자는 AWS 관리 콘솔 또는 AWS CLI에서 역할을 수임하고 이 작업은 AssumeRole API를 사용합니다. AWS 서비스도 같은 API 호출을 통해 AWS 계정의 역할을 수임할 수 있습니다. 페더레이션 사용자는 AssumeRoleWithSAML 또는 AssumeRoleWithWebIdentity API 호출을 사용합니다.

API 호출은 AWS STS(AWS Security Token Service)에 대해 수행됩니다. AWS STS는 IAM 또는 페더레이션 사용자에게 제한된 권한의 임시 작격 증명을 제공하는 웹 서비스입니다. 이 서비스는 액세스 키 ID, 비밀 액세스 키 및 보안 토큰으로 구성된 임시 보안 자격 증명 집합을 반환합니다. 이러한 자격 증명을 사용하여 AWS 리소스에 액세스합니다. AssumeRole API는 일반적으로 교차 계정 액세스 또는 페더레이션에사용됩니다.

STS 자세한 내용

IAM 정책 배정

IAM에서 모든 IAM 정책 유형(관리형 정책 및 인라인 정책)을 생성하고 관리할 수 있는 도구를 제공합니다. IAM 자격 증명(사용자, 그룹, 역할)에 권한을 추가하려면 정책을 생성하고 정책 유효성을 검사한 다음 정책을 자격 증명에 연결합니다. 자격 증명 하나에 여러 정책을 연결할 수 있고 각 정책은 여러 권한을 포함할 수 있습니다.

보통 AWS 리소스에 대한 액세스 권한이 없는 사용자, 애플리케이션 또는 서비스에 액세스 권한을 위임할 때 역할을 사용합니다.

AWS Root 계정

처음 AWS 계정을 생성하면 루트 사용자로 시작합니다. 이 사용자는 계정의 모든 서비스와 리소스에 대한 전체 액세스 권한을 가집니다. 계정을 생성할 때 제공한 이메일 주소와 암호로 로그인하여 루트 사용자 ID에 액세스합니다. 하지만 루트 사용자로 서비스와 리소스를 사용하는 것은 권장되지 않습니다. 따라서 사용자를 추가로 생성한 후 관리합니다.

사용자를 추가한 후 최소 권한의 원칙에 따라 해당 사용자에게 권한을 배정합니다. 최소 권한의 원칙이란 해당 사용자가 정말 필요한 권한까지만 부여하는 것을 뜻합니다. 이렇게 사용자를 생성한 후에는 루트 사용자가 아닌 관리자로 계정을 관리해야합니다.

조금 더 심층적인 보안을 위해서 MFA(Multi-Factor Authetication)을 진행할 수 있습니다. 이 후 AWS 계정에 이를 추가 보안 계층을 적용할 수 있습니다.

루트 계정 상세 보기 / 최소 권한 및 IAM 모범 사례

IAM(Identity and Access Management)

IAM은 AWS 리소스에 대한 액세스를 안전하게 제어하는 데 도움을 주는 웹 서비스입니다. IAM을 사용해 리소스를 사용할 수 있도록 인증(로그인) 및 권한 부여된 대상을 제어합니다.

IAM을 리소스 실행, 구성, 관리, 종료를 위한 액세스 권한을 중앙에서 관리하기 위한 도구로 생각하면 편할 것입니다. IAM을 통해 액세스 권한을 세부적으로 제어할 수 있습니다. 이 제어는 리소스를 기반으로 하며 누가 어떤 API 호출에 대한 권한이 있는지 정의하는 데 도움이 됩니다.

상세 내용

보안 주체

보안 주체는 AWS 리소스에 대한 작업 도는 운영을 요청할 수 있는 엔터티(Entity)입니다. AWS에서 가장 많이 사용되는 보안 주체는 IAM 사용자와 IAM 역할입니다.

이 외에는 EC2(Elastic Compute Cloud)와 같은 AWS 서비스, SAML 2.0(Security Assertio Markup Language 2.0) 제공 업체 혹은 ID 제공 업체(IdP)일 수 있습니다. IdP를 사용할 경우 IAM 외부에서 자격 증명을 관리하게 됩니다. 예를 들어 Amazo, Facebook, Google 등을 통해 로그인할 때는 이러한 외부 자격 증명에 계정의 AWS 리소스를 사용할 권한을 제공할 수 있습니다.

페더레이션 사용자는 IAM을 통해 직접 관리가 되지 않는 외부 자격 증명입니다.

페더레이션 사용자의 자세한 내용

IAM 사용자

IAM 사용자는 AWS 계정 내에 사용자를 뜻합니다. 기본적으로 새 IAM 사용자에게는 권한이 주어지지 않습니다. 개별 IAM 사용자를 생성하는 경우 각 사용자에게 권한을 개별적으로 배정할 수 있다는 이점이 있습니다. 예를 들면 관리자는 여러 서비스를 액세스할 수 있는 권한을 가지고 있고, 감시자는 읽기 전용으로 권한을 줘 관찰만 할 수 있도록 합니다. 개발자는 개발만 할 수 있도록 EC2 인스턴스에 대한 권한만 줍니다.

이러한 방식으로 해당 직무에서 필요한 만큼만 권한을 주는 최소 권한의 원칙을 준수해야합니다.

자세한 내용

AWS API 호출

AWS 서비스에 접속하는 방법은 크게 2가지가 있습니다.

1. AWS 관리 콘솔 액세스 - AWS 웹 콘솔에서 사용자 계정과 암호를 입력해 접속합니다.
2. 프로그래밍 방식 액세스 - IAM 사용자가 API 호출을 수행하거나 AWS CLI(Command Line Interface) 또는 SDK를 사용해야할 수도 있습니다. 이 때 해당 사용자용 액세스 키를 생성해야 합니다.

이 때에도 최소 권한 법칙이 적용됩니다. 만약 AWS 콘솔로만 접속하고 작업을 한다면 액세스 키를 생성하면 안 됩니다.

프로그래밍 방식 액세스

프로그래밍 방식 액세스 권한을 부여하는 경우 AWS CLI 또는 SDK에서 API 호출을 수행하는 데 필요한 자격 증명을 IAM 사용자에게 제공할 수 있습니다. AWS에서는 Java, Python, .NET 등의 프로그래밍 언어용 SDK를 제공합니다.

IAM 사용자에게 프로그래밍 방식 액세스 권한을 부여하면 액세스 키 ID 및 비밀 액세스 키로 구성된 고유한 키 페어가 생성됩니다. 키 페어를 사용하여 AWS CLI를 구성하거나 AWS SDK를 통해 API를 호출할 수 있습니다.

클라이언트에서 AWS CLI를 설정하기 위해 aws configure 명령을 사용합니다. 슬라이드의 예제 코드에는 IAM 사용자를 구성하는 데 필요한 네 가지 요소를 입력해야합니다.

• AWS 액세스 키 ID
• AWS 비밀 액세스 키
• 기본 리전 이름
• 기본 출력 형식(json,yaml, yaml-stream, text, table)

AWS CLI 자세한 내용

IAM 정책을 사용해 권한 설정하기

IAM 사용자가 리소스를 생성하거나 수정하고 태스크를 수행할 수 있또록 하려면 다음 태스크를 수행합니다.

1. IAM 사용자가 필요한 특정 리소스와 API 작업에 액세스할 수 있는 권한을 부여하는 IAM 정책을 생성하거나 기존에 생성되어 있는 정책을 생성합니다.
2. 해당 권한이 필요한 IAM 사용자나 그룹에 정책을 연결합니다.

예를 들어 S3 관리자에게는 S3에 대한 Full Access 권한을 주되 다른 서비스의 권한을 주지는 않습니다. 계정 내의 리소스를 확인해야 하는 감사자에게는 Read Only Access 정책을 연결합니다. 감사자가 다른 것을 수정하거나 삭제할 수 있어서는 안됩니다.

이렇게 최소 권한 원칙은 보안 부분에 있어 매우 강조되는 부분입니다. 권한을 주려는 대상의 직무를 확인하고 적절한 정책을 부여해야 합니다.

AWS Architect 업무

1. 계획
   
   • 실무 책임자와 함께 기술 분야의 클라우드 전략을 수립합니다.
   • 비즈니스 요구 사항과 기타 요구 사항을 충족하는지 솔루션을 분석합니다.
2. 조사
   • 클라우드 서비스의 사양과 워크로드 요구 사항을 조사합니다.
   • 기존 워크로드 아키텍처를 검토합니다.
   • 프로토타입 솔루션을 설계합니다.
3. 빌드
   • 마일스톤, 작업 스트림 및 소유자가 포함된 혁신 로드맵을 설계합니다.
   • 채택 및 마이그레이션을 관리합니다.

수행하는 작업

• 비즈니스 요구에 따라 기술 분야의 클라우드 전략 개발
• 클라우드 마이그레이션 작업 지원
• 워크로드 요구 사항 검토
• 위험성이 높은 문제 해결 방법 관련 지침 제공

자세한 내용

핵심 요소

기술 솔루션 개발은 물리적 건물을 세우는 것과 매우 유사합니다. 기반이 탄탄하지 않으면 그에 따른 문제가 발생하기 마련입니다. 솔루션 개발에서 기반이 엉성하다면 무결성과 기능 저하 등 좋지 못한 방향으로 진행될 것입니다.

AWS에서는 아키텍처의 Framework를 제공함으로써 이 문제를 해결합니다. 이를 AWs Well-Architected Framework라고 합니다. 이 framework에서는 다음 핵심 요소를 중심으로 살펴봅니다.

• 보안 - AWS 보안 모범 사례를 사용해 데이터와 자산을 보호할 수 있는 정책 및 프로세스를 구축해야 합니다.이 때, 작업 및 환경 변경 사항을 실시간으로 모니터링합니다. 이를 통해 추적, 감사를 진행할 수 있습니다.
• 비용 최적화 - 주로 변동이 심한 리소스를 요구하는 경우 비용 효율성을 극대화할 수 있습니다.
• 안정성 - 장애 복구, 수요 증가 처리, 중단 완화 등을 지원합니다.
• 성능 효율성 - 리소스 세트에 대해 효율적인 성능을 제공하는 시스템 아키텍처 설계를 보장합니다.
• 운영 우수성 - 사업 가치를 창출하는 시스템을 실행하고 모니터링할 수 있습니다.
• 지속 가능성 - 클라우드 워크로드를 실행할 때 환경 영향을 최소화하고 이해합니다.

위를 활용해 시스템 장애와 비용 최소화, 비즈니스 및 인프라 심층 분석이 가능합니다.

AWS Well-Architected Tool

셀프 서비스 방식 도구로 이를 사용하면 기존 워크로드의 상태를 검토하고 최신 AWS 아키텍처 모범 사례와 비교할 수 있습니다. 이 도구는 아키텍터 및 관리자가 스스로 워크로드를 컴토하는 데 도움이 되도록 설계되어 있습니다. 

AWS WA Tool 기능

• 워크로드 평가
• 고위험 문제 식별
• 개선 사항 기록

자세한 내용 / 모범 사례

AWS와 상호작용 하는 방법

1. AWS 관리 콘솔: AWS 계정을 관리하고 작업을 수행할 수 있는 GUI(그래픽 사용자 인터페이스)입니다.
2. AWS CLI(Command Line Interface): 명령줄을 사용하여 AWS 서비스를 관리할 수 있는 도구입니다.
3. SDK(소프트웨어 개발 키트): 소프트웨어 개발 프레임워크를 통해 코드를 사용하여 클라우드 인프라를 정의하고 프로비저닝 할 수 있습니다.

이와 같은 도구들은 AWS API에 연결하여 AWS 서비스를 관리하고 리소스를 생성하게 됩니다.

시작하기 앞서 해당 내용들에 링크를 걸어 놓을 생각입니다. 최근 급변하는 기술들 때문에 몇년만 지나도 지금의 내용은 전부 바뀔 수 있기 때문에 업데이트가 수시로 일어납니다. 심지어 교육 진행 중에 교재가 바뀌기도 할 정도라고 하니 블로그나 교육 내용에 집중해보는 것도 좋지만 홈페이지에서 직접 확인해보는 것이 훨씬 정확하다고 할 수 있습니다.

Amazon Web Services(AWS)의 특징

전 세계에서 클라우드 시장 점유율은 AWS가 32%, MS Azure가 23%, Google Cloud Platform(GCP)가 10%로 이 3 가지가 총 65%의 점유율을 가지고 있습니다. 여기서 가장 점유율이 높은 AWS는 컴퓨팅, DB, 스토리지와 같은 200여개의 서비스를 제공합니다. 또한, 사용량만큼 지불하는 종량제 모델을 채택하고 있고 다양한 기업과 공공 기관이 사용하고 있는 클라우드 솔루션입니다. 

AWS로 마이그레이션하는 주된 이유는 복잡성과 리스크를 줄이고, 민첩성을 향상시킨다는 것에 있습니다.

주요 특징

AWS 서비스 종류

AWS는 광범위한 글로벌 클라우드 기반 서비스를 제공한테 여기에는 컴퓨팅, 스토리지, DB, 분석, 네트워킹. 보안 등 다양한 서비스들을 제공하고 있습니다. 이번 SAA(Solutions Architect - Associate)를 공부하며 다룰 내용은 다음과 같습니다.

[보안, 네트워크, 컴퓨팅, 스토리지 ,DBMS, 모니터링, 크기 조정, 자동화, 컨테이너, 서버리스, 엣지 서비스, 백업, 복구]

서비스 종류

인프라 구성

AWS 인프라는 크게 데이터 센터, 가용 영역, 리전, AWS Local Zones, 엣지 로케이션으로 나뉩니다.

1. 데이터 센터
   데이터 센터는 전 세계에 대규모로 분포가 되어있고 AWS 서비스는 AWS 데이터 센터 안에서 작동합니다. 이러한 서비스 뿐만 아니라 자동화 시스템을 구축하고, 서드 파티 감사를 수행함으로써 보안과 규정 준수를 확인합니다.
   
   자세한 보호 방식
   
   
2. 가용 영역
   AWS 리전에 있는 하나 이상의 데이터 센터 그룹을 가용 영역이라고 합니다. 이 가용 영역 안에 있는 데이터 센터들은 고속 프라이빗 링크를 사용해 상호 연결되어 있고, 내결함성을 갖도록 설계되어 있습니다. 이는 고가용성 달성에 사용하게 됩니다.
   
   여러 가용 영역에 인스턴스를 배포하고 인스턴스 하나에 장애가 발생하는 경우 다른 가용 영역의 인스턴스가 요청을 처리할 수 있도록 애플리케이션을 설계할 수 있습니다.
   
   
   • 내결함성(Resilience)
     시스템이 장애가 발생하더라도 원래의 상태로 복구할 수 있는 능력을 말합니다. 내결함성을 달성하기 위해서는 시스템을 설계할 때부터 장애를 고려하고, 장애 발생 시 신속하게 복구할 수 있는 프로세스를 수립해야 합니다.
     
     
   • 고가용성(HA)
     시스템이 장애가 발생하더라도 지속적으로 작동할 수 있도록 하는 것을 말합니다. 고가용성을 달성하기 위해서는 시스템의 구성요소를 이중화하고, 장애를 감지하고 복구할 수 있는 시스템을 구축해야 합니다.
     
     자세한 내용
     
     
3. 리전
   각 AWS 리전은 한 장소(서울, 도쿄 등) 내에서 서로 격리되어 있습니다. 리전 내부에는 물리적으로 분리된 여러 가용 영역으로 구성되어 있습니다. 이런 구성 방식을 통해 강력한 내 결함성 및 안정성을 확보할 수 있습니다.
   
   리전은 서로 격리되어 리전 간 자동 리소스 복제는 불가능합니다. 따라서 리소르를 확인하면 해당 리전에 연결되있는 리소스만 표시됩니다.
   
   • 리전을 선택하기 위해 고려해야 할 것
     1. 거버넌스 및 법적 요구 사항 - 법적 요구 사항을 준수하기 위해 특정 리전을 사용해야 할 수 있습니다.
     2. 지연 시간 - 리전의 위치가 소비자와 가까울수록 더 나은 성능이 나타납니다.
     3. 서비스 가용성 - 모든 AWS 서비스를 모든 리전에서 사용가능한 것은 아닙니다.
     4. 비용 - 리전마다 다른 비용이 부과됩니다. 사용하려는 리전의 서비스 요금을 확인해야 합니다.
        
        자세한 내용
        
4. AWS Local Zones
   최종 사용자 지연 시간이 10밀리초 미만이어야 하는 수요가 많은 애플리케이션에서 사용합니다.
   • 미디어/엔터테인먼트 콘텐츠 생성 - 라이브 프로덕션, 동영상 편집 등
   • 실시간 멀티 플레이 게임
   • 기계 학습 호스팅 및 훈련
   • AR/VR
     
     자세한 내용
5. 엣지 로케이션
   엣지 로케이션은 AWS 서비스 요청자와 가장 가까이 있는 지점을 뜻합니다. 엣지 로케이션은 전 세계 주요 도시에 분포해 있고, 이는 요청을 수신하고 더 빠른 전송을 위해 콘텐츠 사본을 캐시합니다. 덕분에 최종 사용자에게 짧은 지연 시간으로 콘텐츠를 전송할 수 있게 됩니다.
   
   엣지 로케이션을 사용하는 서비스는 대표적으로 CloudFront가 있습니다. CloudFront 에서 기본적으로 사용되는 리전 엣지 캐시는 엣지 로케이션에 유지할 정도로 자주 액세스하지 않는 콘텐츠가 있을 때 활용됩니다. 이런 컨텐츠는 리전 내 엣지 캐시에 수집되므로 오리진 서버에서 해당 콘텐츠를 굳이 검색할 필요가 없어집니다.
   
   예를 들어 미국 리전에 있는 동영상 컨텐츠를 아시아에서 보려고 한다고 가정할 때 아시아 엣지 로케이션에 이 동영상 컨텐츠가 캐시되어 있기 때문에 더 빠르게 컨텐츠를 제공할 수 있습니다.
   
   자세한 내용
   
   
   • AWS Local Zones : 짧은 지연 시간을 요하는 최종 사용자에게 서비스를 배포할 때 사용합니다.
   • 엣지 로케이션 : 사용자에게 빠르게 콘텐츠를 전송하기 위해 데이터를 캐싱할 때 사용합니다.