2024 클라우드 보안 가이드 (AWS, AZURE, GCP)
https://www.skshieldus.com/kor/support/eventDetail.do?idx=501

• 엔지니어링 ⇒ 정량적으로 표현할 수 있는 것, 측정 가능한 정도로 표현(예: 위험도)

• 위험도 및 측정기준 생성∙도츌 ⇒ 평가지표가 필요. 임의로 만드는 것 아닌 근거가 있어야 함. 법 제도, 다른 가이드등 참고

2024 클라우드 보안 가이드

⇒ 문장 이해를 중심으로..

1. 계정 관리

1) 사용자 계정관리

모든 AWS 리소스는 AWS 계정의 소유이고, 리소스 생성 또는 액세스 권한은 권한 정책에 따라 결정됩니다. 계정 관리자는 IAM 자격 증명(즉, 사용자, 그룹, 역할)에 권한 정책을 연결할 수 있으며 적절한 권한을 통한 서비스 관리가 이루어져야 합니다.

사용자가 이용할 수 있다 없다는 정책에 따라 결정됨. 루트 사용자란 내가 가입한 aws 계정의 최고 권한 관리자. 이로부터 사용자 유저가 생성됨.

정책은 2가지 유형이 있음. 관리형 정책과 인라인 정책.

• 관리형 정책(Managed Policies):

• 인라인 정책(Inline Policies):

*() AWS 관리형 정책

서비스 내 FULL ACCESS 등과 같이 중요도가 높은 AWS 관리형 정책은 EC2 서비스 관리/운영자 및 관련 담당자 외에 다른 IAM 계정에 아래와 같은 권한 할당이 되지 않도록 해야합니다. 그중에서도 AWS Admin Console 관리자(AdministratorAccess) 권한은 다수의
IAM 계정에 설정되지 않도록 관리 조치가 필요합니다.**

AWS Admin Console 관리자(AdministratorAccess) 권한이란 높은 권한을 가진 사용자를 말함.

AWS 계정에 대한 루트 사용자 모범 사례
https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/root-user-best-practices.html

AWS 계정을(를) 처음 생성하면 계정의 모든 AWS 리소스에 대한 완전한 액세스 권한이 있는 기본 보안 인증 세트로 시작합니다. 이 자격 증명을 AWS 계정 루트 사용자라고 합니다. 루트 사용자 보안 인증이 필요한 작업이 있는 경우가 아니면 AWS 계정 루트 사용자에게 액세스하지 않는 것이 좋습니다. 권한이 높은 보안 인증이 무단 사용에 노출되지 않도록 하려면 루트 사용자 보안 인증과 계정 복구 메커니즘을 안전하게 보호해야 합니다.

(*)불필요한 계정 예시

1. 비 임직원 계정 (협력사 공통 계정)
   ⇒ 계정하나로 돌려쓰면 책임소재 불분명 해짐. 계정이라는 것은 사용자를 식별해야함

2. 테스트 계정 (testuser, test01, test02....)

3. 미사용 계정 (퇴직 및 휴직자)

IAM 그룹에 포함되지 않은 단일 사용자 권한 확인

그룹이란 같은 권한의 사용자의 모임을 말한다. 그룹으로 일괄적으로 권한 부여가 가능해 관리가 쉬워짐.

IAM 그룹에 포함되지 않은 단일 사용자 계정 전체 권한 확인

⇒ 권한이 직접 부여되어 있는 단일 사용자 계정 확인

관리자의 권한이 필요없는 사용자가 권한을 가지고 있는지 판단.

그룹을 만들고 정책을 만드는게 좋은 방법임.

2) 사용자 계정 단일화 관리

적절한 IAM 계정 사용

1인 1계정 이 원칙. 계정 아이디를 발급하는 이유는 시스템 입장에서 사용자를 식별하기 위해서다. 즉 사용자를 인지하는 기준. 다른 사용자의 계정을 가지고 있으면 계정이 도용된 것, 하나의 계정을 여러 사람이 쓴다면 책임소재를 알 수 없다.

⇒ 실제 사용자가 사용하는 계정이 뭔지 확인하고 불필요한 사용자 계정은 삭제한다.

3) 사용자 계정 식별관리

태그 ⇒ 리소스를 정리하고 그룹화하여 관리하는 데 도움이 되는 도구. 빠르게 뭔가를 찾을 때 사용. 예를 들어,AWS 계정에서 가상 서버를 실행한다고 가정하면, 이 서버에는 "프로젝트", "부서", "용도"와 같은 메타데이터를 포함하는 태그를 추가할 수 있다. 후에 태그에 해당하는 리소스만 뽑아서 볼수 있다.

리소스 정보가 사용자 태그에 설정되어 있는 것이 좋다.

4) IAM 그룹 사용자 계정 관리

IAM 그룹은 IAM 사용자들의 집합으로 AWS 사용자들에 대한 권한을 쉽게 관리할 수 있습니다. 그룹에 대한 IAM 권한 적용 시 그룹 내 사용자들에게 일괄 적용이 되기 때문에 그룹 별 적절한 권한을 할당하여 사용해야 합니다.

• 그룹에 속한 사용자들에게 꼭 필요한 권한만 그룹에 설정(부여)
  적절한 권한 할당이란 최소 권한 설정을 말함.

• 꼭 필요한 사용자만 그룹에 속하는 것을 보장
  그룹에 속해있는 사용자들은 정책을 그대로 받기 때문에 그룹 내 불필요한 사용자를 확인하고 삭제해야함.

5) Key Pair 접근 관리

EC2는 키(Key)를 이용한 암호화 기법을 제공합니다. 해당 기법은 퍼블릭/프라이빗 키를 통해 각각 데이터의 암호화 및 해독을 하는 방식으로 여기에 사용되는 키를 ‘Key Pair’ 라고 하며, 해당 암호화 기법을 사용할 시 EC2의 보안성을 향상시킬 수 있으므로 EC2 인스턴스 생성 시 Key Pair 등록을 권장합니다. 또한, Amazon EC2에 사용되는 키는 ‘2048비트 SSH-2 RSA 키’이며, Key Pair는 리전당 최대5천 개까지 보유할 수 있습니다.

퍼블릭/프라이빗 키 ⇒ 비대칭키 암호화 방식 = 공개키 암호화 방식

• 퍼블릭 키(Public Key): 공개되어 있으며, 누구나 암호화된 메시지를 전송할 때 사용할 수 있는 키입니다. 이 키는 데이터를 암호화하는 데 사용됩니다.

• 프라이빗 키(Private Key): 비밀로 유지되어야 하며, 해당 키를 소유한 사용자만이 암호화된 메시지를 해독할 수 있습니다. 이 키는 암호화된 데이터를 해독하는 데 사용됩니다.

데이터의 암호화 및 해독을 하는 방식 :

공개 키 암호화 방식으로, 데이터의 기밀성을 보장하기 위해 사용된다. 공개 키 암호화 방식은 송신자와 수신자가 각각 공개 키와 개인 키라는 서로 다른 키 쌍을 가지고 있다.

송신자가 데이터를 전송할 때, 데이터를 수신자의 공개 키로 암호화한다. 이러한 과정을 통해 암호화된 데이터는 수신자만이 자신의 개인 키로만 해독할 수 있습니다. 이것은 데이터의 기밀성을 보장하고, 무단 접근을 방지하는 데 도움이 된다.

Key Pair :

AWS EC2 인스턴스에 대한 SSH 액세스를 허용하는 데 사용되는 보안 인증서 쌍. 이러한 인증서 쌍은 공개 키와 개인 키로 구성되며, SSH 프로토콜을 통해 EC2 인스턴스에 연결할 때 사용된다.

일반적으로 EC2 인스턴스를 생성할 때 Key Pair를 선택하거나 생성한다. 이 과정에서 AWS는 공개 키를 인스턴스에 배치하고 해당 개인 키를 사용자에게 다운로드하도록 제공합니다. 사용자는 개인 키를 안전하게 보관하고, SSH 클라이언트를 사용하여 해당 키를 통해 EC2 인스턴스에 액세스할 수 있다.

윈도우 환경에서 RSA 암호화 알고리즘을 이용한 키 쌍을 생성한 후 키 페어로 등록

#1 윈도우용 OpenSSL 설치

https://slproweb.com/products/Win32OpenSSL.html

#2 개인키 생성 (관리자 권한으로 명령 프롬프트를 실행해서)

C:\Users\r2com> cd "c:\Program Files\OpenSSL-Win64\bin"	⇐ openssl.exe 파일이 위치한 곳

c:\Program Files\OpenSSL-Win64\bin> openssl genrsa -out private_key.pem 1024⇐ 개인키 생성

c:\Program Files\OpenSSL-Win64\bin>  type private_key.pem

c:\Program Files\OpenSSL-Win64\bin> <openssl rsa -in private_key.pem -out public_key.pem -pubout

c:\Program Files\OpenSSL-Win64\bin> type public_key.pem

보안강도 = 비도

• 보안 강도(Security Strength):

보안 강도는 암호화 알고리즘의 안전성을 나타내는 지표입니다. 일반적으로 더 높은 보안 강도는 더 안전한 암호화를 의미합니다.
암호화 키의 길이나 알고리즘의 복잡성 등에 비례해서 보안 강도에 영향을 줍니다. 키의 길이가 길고, 알고리즘이 복잡할수록 보안 강도는 더 높아집니다.

• 비도(Entropy):

비도는 암호화 키나 랜덤 데이터의 예측 불가능성을 나타냅니다. 즉, 비도가 높을수록 암호화 키나 랜덤 데이터가 예측하기 어려워집니다.
예를 들어, 암호화 키가 예측 가능한 패턴을 가지고 있다면 비도가 낮다고 할 수 있습니다. 따라서 안전한 암호화를 위해서는 높은 비도가 필요합니다.

즉, 보안 강도는 암호화 알고리즘의 안전성을 측정하는 지표이며, 비도는 예측 불가능성을 나타내는 요소입니다.

⇒ Key Pair(PEM)를 통해 EC2 인스턴스에 접근해야 한다.

6) Key Pair 보관 관리

• Key Pair 는 타 사용자가 확인이 가능한 공개된 위치에 보관하게 될 경우 EC2 Instance 에 무단으로 접근이 가능해지므로 비인가자가 쉽게 유추 및 접근이 불가능한 장소에 보관해야 합니다

• 개인 키를 안전한 장소에 보관해야 하는 이유는 개인 키가 노출되면 보안 위험이 발생하기 때문입니다. 개인 키가 노출되면 암호화된 데이터가 해독될 수 있고, 해당 키를 가진 사용자의 권한으로 인스턴스에 액세스할 수 있게 됩니다.

• S3 프라이빗 버킷은 외부에서의 접근을 막고 데이터를 안전하게 보관할 수 있는 방법 중 하나입니다. S3는 AWS에서 제공하는 강력한 액세스 제어 기능을 사용하여 허가되지 않은 사용자의 접근을 차단할 수 있습니다. 버킷 정책과 IAM 정책을 통해 특정 사용자나 그룹에 대한 액세스를 제어할 수 있습니다. 따라서 허가받지 않은 사용자가 개인 키에 접근하는 것을 방지할 수 있습니다.

개인적으로 보관하는 것이 좋지않은 이유

• 물리적 보안 부족: 개인적으로 보관된 키는 사용자의 컴퓨터나 저장 매체에 저장되어 있습니다. 이러한 환경에서는 물리적인 보안이 부족할 수 있으며, 컴퓨터가 도난당하거나 탈취될 경우 키가 노출될 수 있습니다.

• 손실 위험: 개인적으로 보관된 키는 개인의 책임 하에 보호되어야 합니다. 그러나 재해나 사고로 또는 퇴사로 인해 키가 손실될 경우 데이터에 액세스할 수 없게 될 수 있습니다. 이는 신뢰성 있는 백업 및 재해 대응 계획이 없는 경우에 더욱 심각한 문제가 될 수 있습니다.

• 협업 및 공유 어려움 :

• 액세스 및 권한 관리: 여러 사용자가 동일한 키에 액세스해야 하는 경우 키의 액세스 및 권한을 관리하기 어려울 수 있습니다. 특정 사용자에게만 필요한 권한을 부여하고 다른 사용자에게는 권한을 제한하는 것은 복잡하고 오류가 발생하기 쉽습니다.

• 변경 관리: 키가 변경되거나 업데이트될 경우 이를 공유하고 협업하는 모든 사용자에게 적용되어야 합니다. 그러나 개인적으로 보관된 키의 경우 이러한 변경 사항을 효율적으로 관리하기 어려울 수 있습니다.

7) Admin Console 관리자 정책 관리

• AWS Cloud 사용을 위해 처음 발급한 계정 (IAM 사용자 계정과 달리 모든 서비스에 접근할 수 있는 최고 관리자 계정)
  ⇒ AWS 계정 루트 사용자

• Cloud 서비스 특성 상 인터넷 연결이 가능한 망에서 계정정보를 입력하여 WEB Console에 접근하게 됩니다. 이는 최고 권한을 보유하고 있는 관리자 계정이 아닌 권한이 조정된 IAM 사용자 계정을 기본으로 사용해야 보다 안전한 접근이 이뤄질 수 있습니다.

• 본적으로 AWS의 관리자 권한을 가진 계정은 모든 AWS 리소스에 대한 액세스 권한을 가지고 있으며, 이 계정이 탈취되거나 악용될 경우 심각한 보안 문제를 초래할 수 있습니다. 따라서 보다 안전한 접근을 위해 관리자 계정 대신에 IAM 사용자 계정을 생성하고 해당 계정에 필요한 권한만을 부여하는 것이 좋습니다.

• IAM 사용자는 필요한 권한만을 가지고 있기 때문에 보안 리스크를 최소화할 수 있습니다. 또한 IAM 사용자를 통해 AWS 리소스에 대한 접근을 추적하고 감사할 수 있어서 보안 상황을 더 잘 파악하고 대응할 수 있습니다

• 권한이 조정된 IAM 사용자 계정
  ⇒ 꼭 필요한 최소 권한만 사용자 또는 사용자 그룹에 부여된 사용자

8) Admin Console 계정 Access Key 활성화 및 사용주기 관리

• Access Key는 AWS 리소스에 액세스할 때 사용되는 비밀번호와 같은 것이다. 이 비밀번호를 알고 있다면 AWS CLI나 API를 통해 AWS 서비스에 접근하고 다양한 작업을 수행할 수 있다. 예를 들어, 서버를 생성하거나 데이터베이스를 관리하는 등의 작업을 할 수 있다.

• Access Key는 AWS의 CLI 도구나 API를 사용할 때 필요한 인증수단으로 생성 사용자에 대한 결제정보를 포함한 모든 AWS 서비스의 전체 리소스에 대한 권한을 갖고있으므로 유출 시 심각한 피해가 발생할 가능성이 있다. 예를들어 누군가가 AWS 계정에 접근하여 원치 않는 작업을 수행할 수 있다. 이는 매우 위험한 상황이며, 예기치 않은 과금이 발생하거나 중요한 데이터가 유출될 수 있다. 특히 AWS Admin Console Account의 Access Key가 유출된다면, 이 계정에는 모든 AWS 서비스에 대한 권한이 있기 때문에 피해가 더 커질 수 있다.

• 따라서 보안을 위해 사용하지 않는 Access Key는 정기적으로 삭제하고, 특히 AWS Admin Console Account에 대한 Access Key는 사용하지 않는 것이 좋다. 사용해야 하는 경우에는 안전한 방법으로 보관하고 필요하지 않을 때는 반드시 삭제해야 합니다.

• CLI 도구나 API를 사용 : 프로그램 방식으로 AWS 리소스를 사용

• AWS Admin Console Account : AdministratorAccess 권한을 가진 사용자

※ Access Key 관리 주기

• Key 수명(60일 이내):
  Access Key는 보안을 위해 주기적으로 갱신되어야 합니다. 보통 60일 이내로 설정하여 매 60일마다 새로운 Access Key를 생성하고 이전 키를 비활성화하는 것이 좋습니다.

• 비밀번호 수명(60일 이내):
  Access Key와 연결된 비밀번호도 주기적으로 변경되어야 합니다. 이 비밀번호는 Access Key를 생성할 때 설정되며, 보통 60일마다 변경하는 것이 좋습니다.

• 마지막 활동(30일 이내):
  Access Key를 사용한 활동을 모니터링하여 30일 이내에 최근 활동이 있었는지 확인합니다. 만약 최근에 사용하지 않았다면 해당 Access Key를 비활성화하고 필요한 경우 삭제합니다.

⇒ AWS Admin Console 계정에 Access Key가 존재하지 않고 IAM 사용자 계정에 대한 Access Key 사용 주기가 60일 이내여야 한다.

9) MFA (Multi-Factor Authentication) 설정

• MFA(다중 인증 요소)는 사용자가 로그인할 때 비밀번호 외에 추가적인 인증 수단을 요구하는 보안 기술입니다.. MFA는 일반적으로 세 가지 요소를 사용합니다

• 지식 요소(Knowledge Factor):
  사용자의 암호 또는 비밀번호와 같이 사용자가 알고 있는 정보입니다.

• 소유 요소(Possession Factor):
  사용자가 보유하고 있는 특정 장치나 토큰과 같이 사용자가 소유하고 있는 것입니다. 소유 OTP, 인증서, ...

• 어울림 요소(Inherence Factor):
  생체 인식 기술(지문, 홍채, 얼굴 인식 등)을 사용하여 사용자의 고유한 생체 특성을 인증하는 것입니다.

• MFA를 활성화하면 사용자가 AWS Management Console 또는 AWS API에 로그인할 때 사용자 이름과 비밀번호 외에도 MFA 장치(예: 스마트폰 앱, 하드웨어 토큰)의 인증 응답을 제공해야 합니다. 이를 통해 외부에서의 불법적인 접근을 방지하고 계정의 안전성을 높일 수 있습니다.

• AWS Multi-Factor Authentication(MFA)은 사용자 이름과 암호 외에 보안을 한층 더 강화할 수 있는 방법으로 MFA를 활성화하면 사용자가 AWS 웹 사이트에 로그인할 때 사용자 이름과 암호뿐만 아니라 AWS MFA 디바이스의 인증 응답을 입력하라는 메시지가 표시됩니다. 이러한 다중 요소를 통해 AWS 계정 설정 및 리소스에 대한 보안을 높일 수 있습니다.

⇒ AWS 계정 및 IAM 사용자 계정 로그인 시 MFA가 활성화 되어 있어야 한다.

Root 사용자의 경우

IAM 사용자 계정인 경우

TOTP Authenticator
https://chromewebstore.google.com/detail/totp-authenticator/ibpjepoimpcdofeoalokgpjafnjonkpc?hl=ko

⇒ MFA 인증을 사용하지 않고 SSO 인증을 통해서 로그인할 경우 양호로 처리될 수 있음

• SSO(Single Sign-On)는 한 번의 인증으로 여러 개의 서비스에 접근할 수 있는 인증 메커니즘입니다. 일반적으로 SSO를 통해 사용자는 여러 서비스에 대해 단일 인증을 제공하므로 편리성이 높아집니다.

• 그러나 보안 측면에서는 MFA(Multi-Factor Authentication)보다는 낮은 수준의 보안을 제공합니다. SSO는 사용자가 한 번의 인증으로 여러 서비스에 액세스할 수 있도록 하지만 추가적인 보안 요소(예: MFA)를 사용하지 않습니다. 따라서 SSO만을 사용하여 로그인할 경우 보안 수준이 낮을 수 있습니다.

• AWS에서 인증하는것이 아니라 다른 인증방법이다.

10) AWS 계정 패스워드 정책 관리

• AWS Admin Console Account(ROOT 계정) 계정 및 IAM 사용자 계정의 암호 설정 시 일반적으로 유추하기 쉬운 암호를 설정하는 경우 비 인가된 사용자가 해당 계정을 획득하여 접근 가능성이 존재합니다

기준 : 키사에 패스워드 선택 및 이용안내서
https://www.kisa.or.kr/2060305/formpostSeq=14&lang_type=KO#fnPostAttachDownload

• 패스워드는 아래의 4가지 문자 종류 중 2종류 이상을 조합하여 최소 10자리 이상 또는 3종류 이상을 조합하여 최소 8자리 이상의 길이로 구성

• 영문 대문자(26개), 영문 소문자(26개), 숫자(10개), 특수문자(32개

• 패스워드 최소길이

패스워드 추측공격을 피하기 위하여 패스워드 최소길이가 설정되어 있는지 점검함 패스워드 최소길이가 설정되어 있지 않거나 짧게 설정되어 있을 경우 취약한 패스워드를 사용함으로 인해 악의적인 사용자가 패스워드를 쉽게 유추 할 수 있음

• 패스워드 최대 사용기간

패스워드가 임의의 경로를 통해 유출되었을 때, 임의로 접속한 사용자가 언제든 다시
접속할 수 있는 환경을 방지하기 위해 패스워드 날짜 제한을 점검함

• 패스워드 최소 사용기간

패스워드가 임의의 경로를 통해 유출되었을 때, 임의로 접속한 사용자가 언제든 다시
접속할 수 있는 환경을 방지하기 위해 패스워드 날짜 제한을 점검함

• 이전 패스워드 기억

이전에 사용하였던 패스워드를 기억하여 패스워드 변경 시 기존에 사용하였던 패스워드

재사용 금지
-패스워드 길이는 8자 이상 설정하는 것을 권고
-패스워드 최대 사용 기간을 60일 이하로 설정할 것을 권고
-패스워드 최소 사용 기간을 1일 이상으로 설정할 것을 권고

• 암호 만료 활성화 및 재사용 제한

-암호 만료 활성화, 암호 만료일은 90일 이하여야 함
-암호 재사용 제한 최소 1개 이상이어야 함

⇒ Admin Console 및 IAM 계정의 패스워드 복잡성 기준 준수 및 암호 만료/재사용 제한을 설정해야 한다.

11) EKS 사용자 관리

EKS = Elastic Kubernetes Service란?

• AWS에서 제공하는 완전히 관리되는 Kubernetes 서비스로, 도커로 패키징된 컨테이너화된 애플리케이션을 효율적으로 관리하고 배포하는 데 사용됩니다. AWS EKS를 사용하면 쿠버네티스 클러스터를 간편하게 설정하고 운영할 수 있으며, AWS의 다양한 기능과 통합된 환경을 활용할 수 있습니다.

---

---

---

사실이 아닌 것을 사실이라고 생각하는 것을 가상이라고 한다. 가상화란 실제로 존재하진 않지만 가상의 컴퓨터 환경을 만들어 여러 운영체제(OS)나 소프트웨어를 시뮬레이션 할 수 있는 기술이다.

하이퍼바이저(Hypervisor)는 하드웨어와 OS와의 소통을 돕는 '통역사'역할을 맡게 된다. 각종 OS들이 보낸 명령을 통일된 명령어로 번역하거나 반대로 하드웨어에서 보내는 리소스들을 OS들에게 분배하는 것이다. 결과적으로 하이퍼바이저 가상화 두면 여러 리소스들을 한 대 처럼 운영하거나 하나의 리소스를 여러대로 나누어 탄력적인 운영이 가능하다.

하지만 하이퍼 바이저가 모든 명령을 컨트롤하고 가상 환경을 구축하다 보니 여러 OS를 구동할 수록 힘이 떨어지고 성능과 속도에 브레이크가 걸리는 단점이 있다.

그래서 등장한 것이 컨테이너 가상화 기술이다. 많은 화물을 적은 비용으로 옮기기 위해 개발된 컨테이너 처럼 컴퓨팅 환경을 모듈화 하여 격리하는 것을 컨테이너라고 부른다. 하이퍼바이저 없이 각각의 앱을 밀키트처럼 포장해두고 조리하는 주방을 분리하는 것이다. 주방을 옮겨도 밀키트만 챙겨가면 바로 요리를 시작할 수있는 간편한 방식이다. 여기서 주방 역할을 하는것이 도커다.

- 도커(Docker)

도커는 소프트웨어를 밀봉된 상자 안에 넣는 것으로 생각할 수 있다. 이 상자 안에는 소프트웨어가 실행되기 위해 필요한 모든 것이 들어있다. - 필요한 프로그램, 라이브러리, 설정 등. 이 상자를 호스트 컴퓨터에서 실행할 수 있고, 호스트 시스템과 독립적으로 작동한다.

도커는 개발자가 소프트웨어를 개발하고, 배포하는 과정을 간단하게 만들어준다. 여러 환경에서도 동일한 소프트웨어를 실행할 수 있다. 예를 들어, 개발 환경과 운영 환경이 달라도 도커를 사용하면 소프트웨어가 일관되게 동작하게 할 수 있다. 이렇게 하면 애플리케이션의 이식성이 높아지고, 확장성이 좋아져요. 도커는 개발과 배포를 더 효율적으로 만들어주는 강력한 도구라고 할 수 있어요.

도커는 개발자가 애플리케이션을 컨테이너화하고 배포할 수 있게 해주는 플랫폼입니다.

개발자는 도커를 사용하여 소프트웨어를 컨테이너로 패키징할 수 있습니다.

이 컨테이너에는 애플리케이션을 실행하는 데 필요한 모든 것이 포함되어 있습니다 (프로그램, 라이브러리, 설정 등).

도커는 애플리케이션을 호스트 시스템과 독립적으로 실행되도록 보장하며, 환경의 일관성을 유지하고 이식성과 확장성을 향상시킵니다.

개발과 배포 과정을 단순화하고 효율화하여 개발자들이 빠르게 애플리케이션을 개발하고 배포할 수 있도록 도와줍니다.

- 쿠버네티스(Kubernetes)

쿠버네티스는 애플리케이션을 컨테이너 안에 담아서, 그 컨테이너들을 한데 묶어서 운영하는 플랫폼이다. 이걸 주방에 비유하면, 쿠버네티스는 주방장처럼 요리들을 조리하고 관리하는 역할이다..

도커 컨테이너는 각각의 음식재료를 밀키트처럼 포장하는 것이다. 쿠버네티스는 이런 도커 컨테이너들을 한데 모아서, 효율적으로 조리하고 배달하는 주방장 역할을 한다.

쿠버네티스가 주방장이라면, 도커는 주방에서 사용하는 밀키트나 조리도구 정도로 비유할수 있다. 도커를 사용하면 애플리케이션을 쉽게 컨테이너화할 수 있고, 쿠버네티스를 통해 그 컨테이너들을 효율적으로 관리하고 운영할 수 있다.

쿠버네티스는 컨테이너 오케스트레이션 플랫폼으로, 여러 개의 컨테이너화된 애플리케이션을 자동으로 배포, 확장 및 관리하는 기능을 제공합니다.

쿠버네티스는 컨테이너 클러스터를 구축하고, 컨테이너를 여러 노드에 분산시키며, 컨테이너의 상태를 모니터링하고 자동으로 복구합니다.

도커와 함께 사용되어, 도커로 컨테이너화된 애플리케이션을 쿠버네티스 클러스터에 배포하고 관리할 수 있습니다.

쿠버네티스는 애플리케이션의 가용성, 확장성 및 안정성을 향상시키는데 도움을 줍니다.

커는 개발자가 개발된 애플리케이션을 컨테이너화하여 패키징하고 실행하는 도구이며, 쿠버네티스는 이러한 컨테이너화된 애플리케이션을 효율적으로 관리하고 배포하는 플랫폼입니다. 함께 사용되어 개발부터 운영까지의 전체 라이프사이클을 지원합니다.

- AWS Elastic Kubernetes Service(EKS)

이러한 쿠버네티스를 AWS에서 제공하는 완전 관리형 서비스입니다. 개발자나 운영팀은 Kubernetes 클러스터를 직접 구축하거나 관리할 필요 없이, AWS에서 관리해주는 완전 관리형 서비스를 통해 컨테이너 기반 애플리케이션을 운영할 수 있습니다. EKS는 컨테이너 오케스트레이션과 관련된 복잡한 작업들을 자동화하여 개발자들이 애플리케이션을 신속하게 배포하고 확장할 수 있도록 도와줍니다.

• 컨테이너 오케스트레이션이란 여러 대의 컴퓨터에서 실행되는 컨테이너화된 애플리케이션을 자동으로 관리하고 조정하는 것이다.

---

---

---

• 기본적으로 AWS 계정은 리소스에 대한 액세스를 최소한의 사용자 수와 권한으로 관리해야 합니다.

• AWS는 IAM 사용자에게 EKS 클러스터에 대한 액세스 권한을 부여해야 할 때 특정 쿠버네티스 RBAC 그룹에 매핑되는 사용자의 "aws-auth" ConfigMap을 제공합니다.

• 이 ConfigMap은 초기에는 노드를 클러스터에 연결하는 용도로 만들어졌지만, IAM 보안 주체에 대한 역할 기반 액세스 제어(RBAC) 액세스를 추가할 수도 있습니다.

• 실제 동작 방식은 사용자 ID가 AWS IAM 서비스에 의해 인증되면 kube-apiserver는 'kubesystem' 네임스페이스에서 'aws-auth' ConfigMap을 읽어 사용자와 연결할 RBAC 그룹을 결정합니다.

• "aws-auth" ConfigMap을 사용할 때 주의할 점은 Amazon EKS 클러스터를 생성할 때, 클러스터를 생성하는 IAM 보안 주체에게는 "system:masters" 권한이 자동으로 부여되어 관리되지 않습니다.

• 따라서 전용 IAM 역할로 클러스터를 생성하고 정기적으로 감사하는 것이 좋습니다.

• 이러한 역할을 통해 클러스터에서 일반적인 작업을 수행하는 데 사용해서는 안 됩니다.

• 또한, "aws-auth" ConfigMap을 변경해야 할 때는 주의해야 합니다.

• 잘못된 형식의 ConfigMap으로 인해 클러스터에 대한 접근 권한을 잃을 수 있으므로, 변경이 필요한 경우 eksctl, keikoproj의 aws-auth, AWS IAM Authenticator CLI와 같은 도구를 사용해야 합니다.

⇒ EKS 리소스 접근을 위한 ConfigMap(RBAC) 내 인가된 사용자만 설정해야 한다.

12) EKS 서비스 어카운트 관리

• 서비스 어카운트는 파드(pod)에 쿠버네티스 RBAC 역할을 할당할 수 있는 특수한 유형의 개체이며, Cluster 내의 각 네임스페이스에 기본 서비스 어카운트가 자동으로 생성됩니다.

파드(pod) :
쿠버네티스에서 사용하는 가장 작은 단위
하나 이상의 컨테이너 어플리케이션을 묶어서 실행하는 단위

• 특정 서비스 어카운트을 참조하지 않고 네임스페이스에 파드를 배포하면, 해당 네임스페이스의 파드에 자동으로 할당되고 서비스 어카운트의(JWT) 토큰은 특정 경로의 볼륨으로 파드에 마운트됩니다.

• 애플리케이션이 Kubernetes API를 호출할 필요가 없는 경우 애플리케이션 의 PodSpec에서 automountServiceAccountToken 속성을 false로 설정하거나 각 네임스페이스의 기본 서비스 어카운트를 패치하여 더 이상 파드에 자동으로 마운트되지 않도록 해야 합니다.

⇒ 네임스페이스 또는 서비스 어카운트 설정 automountServiceAccountToken 값을 False로 설정해야한다.

13) EKS 불필요한 익명 접근 관리

• 클라우드 환경 내에서는 모든 API 및 리소스 작업 시에 대해 익명 사용자의 접근을 비활성화하여 이용해야 합니다.

• 쿠버네티스는 기본 제공 사용자 “system:anonymous” 에 대한 RoleBinding 또는 ClusterRoleBinding을 생성하여 익명 액세스 권한을 부여할수 있습니다.

• kubectl rbac-tool 또는 rbac-lookup 도구를 사용하여 “system:anonymous” 사용자가 Cluster에 대해 갖는 권한을 조회 할수 있으며 “system:public-info-viewer” 권한 외의 ClusterRole 또는 모든 역할은 “system:anonymous” 또는 “system:unauthenticated” 그룹에 바인딩되지 않도록 해야합니다.

• Kubernetes/EKS 버전 1.14 이전에는 “system:unauthenticated” 그룹이 기본적으로 “system:discovery” 및 “system:basic-user” Cluster 역할에 연결됩니다.

• Cluster를 버전 1.14 이상으로 업데이트했더라도 Cluster를 업데이트해도 이런 권한이 취소되지 않으므로 Cluster에서 이런 권한이 계속 활성화될 수 있어 유의해야합니다.

※ 특정 API에서 익명 액세스를 활성화해야 하는 경우 익명 사용자가 특정 API만 액세스할 수 있도록 하고 인증 없이 해당 API를 노출해도 Cluster가 취약해지지 않도록 해야 하며 정보보안팀 확인 또는 담당자 승인을 득한 후 사용하시기 권고 드립니다