클라우드 기반 취약점 진단 및 대응 실무
📌 2024 클라우드 보안 가이드 (AWS, AZURE, GCP)
https://www.skshieldus.com/kor/support/eventDetail.do?idx=501
1. 계정 관리
1.1 사용자 계정 관리
모든 AWS 리소스는 AWS 계정의 소유이고, 리소스 생성 또는 액세스 권한은 권한 정책에 따라 결정됩니다. 계정 관리자는 IAM 자격 증명(사용자, 그룹, 역할)에 권한 정책(관리형 정책, 인라인 정책)을 연결할 수 있으며 적절한 권한(최소 권한의 원칙에 따른 권한 부여)을 통한 서비스 관리가 이루어져야 합니다.
AWS 관리형 정책
서비스 내 FULL ACCESS 등과 같이 중요도가 높은 AWS 관리형 정책은 EC2 서비스 관리/운영자 및 관련 담당자 외에 다른 IAM 계정에 아래와 같은 권한 할당이 되지 않도록 해야합니다. 그중에서도 AWS Admin Console 관리자(AdministratorAccess) 권한은 다수의 IAM 계정에 설정되지 않도록 관리 조치가 필요합니다.
AWS 계정에 대한 루트 사용자 모범 사례
https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/root-user-best-practices.html
AWS 계정을(를) 처음 생성하면 계정의 모든 AWS 리소스에 대한 완전한 액세스 권한이 있는 기본 보안 인증 세트로 시작합니다. 이 자격 증명을 AWS 계정 루트 사용자라고 합니다. 루트 사용자 보안 인증이 필요한 작업이 있는 경우가 아니면 AWS 계정 루트 사용자에게 액세스하지 않는 것이 좋습니다. 권한이 높은 보안 인증이 무단 사용에 노출되지 않도록 하려면 루트 사용자 보안 인증과 계정 복구 메커니즘을 안전하게 보호해야 합니다.
1.2 IAM 사용자 계정 단일화 관리
1인 1계정 발급 원칙
1.3 IAM 사용자 계정 식별 관리
'태그'
→ IAM 사용자에 대한 액세스 구성, 추정 또는 제어가 가능
1.4 IAM 그룹 사용자 계정 관리
IAM 그룹은 IAM 사용자들의 집합으로 AWS 사용자들에 대한 권한을 쉽게 관리할 수 있습니다.
그룹에 대한 IAM 권한 적용 시 그룹 내 사용자들에게 일괄 적용이 되기 때문에 그룹 별 적절한 권한(그룹에 속한 사용자들에게 꼭 필요한 권한만 그룹에 설정(부여), 꼭 필요한 사용자만 그룹에 속하는 것을 보장)을 할당하여 사용해야 합니다.
1.5 Key Pair 접근 관리
EC2는 키(Key)를 이용한 암호화 기법을 제공합니다.
해당 기법은 퍼블릭/프라이빗 키(비대칭키 암호화 방식 = 공개키 암호화 방식)를 통해 각각 데이터의 암호화 및 해독을 하는 방식(기밀성을 보장하기 위해 송신자가 수신자의 공개키로 암호화해서 전달 수신자는 자신의 개인키로 복호화)으로
여기에 사용되는 키를 "Key Pair"라고 하며,
해당 암호화 기법을 사용할 시 EC2의 보안성을 향상시킬 수 있으므로 EC2 인스턴스 생성 시 Key Pair 등록을 권장합니다.
또한, Amazon EC2에 사용되는 키는 "2048비트 SSH-2 RSA 키" 이며, Key Pair는 리전당 최대 5천 개까지 보유할 수 있습니다.
윈도우 환경에서 RSA 암호화 알고리즘을 이용한 키 쌍을 생성한 후 키 페어로 등록
https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/verify-keys.html
#1 윈도우용 OpenSSL 설치
https://slproweb.com/products/Win32OpenSSL.html
#2 개인키 생성 (관리자 권한으로 명령 프롬프트 실행)
# openssl.exe 파일이 위치한 곳
C:\Windows\system32> cd "c:\Program Files\OpenSSL-Win64\bin"
# 개인키 생성
c:\Program Files\OpenSSL-Win64\bin> openssl genrsa -out private_key.pem 1024
c:\Program Files\OpenSSL-Win64\bin> type private_key.pem
-----BEGIN PRIVATE KEY-----
MIICdgIBADANBgkqhkiG9w0BAQEFAASCAmAwggJcAgEAAoGBALcpE3ClkgS4QOPH
R4EM0EQKjmYCtZgDxgREexn7aH5naoUgN7Zya1x1lYBIdTE5DghmoQoUVq7NqNZy
LdOjoEiKAFFiFpAA0eeHbvtZb/+QzIQ6qmeGTvlXnhkfz7i4CZ5j6tzwSymm0AcS
ceJt33VXmgaAeCUWEudO9eei49HhAgMBAAECgYEAlhkwWDEnT3zbmI6311bz2b64
4Xo47OGyxc6E/07bXDNNxNkZLwfnWbb2lFFM0NDL4jCQqlzuiIP7Z/nb+kNuVoDV
7XQbtEmJAIABnMaIELRTLSGrh3pxZXpP8ddMobJPNZ6Ek6W8qqUo2tJwsGeTu6mW
NGKDReR0Ikf3fjxEsV0CQQDd161XmKix0a4sQox3vAulHLsAaMxb8hrk3h/siKcX
twWij0i7GJLFq62YxL7Q2unoF+wrwO5acPDi7oROPKSLAkEA01ytKgICEmp8XDn4
qN8ZV2XvU+gwTZkdSuO45JQnhjnW3FX1VKQzFi/omwCB/G9ahOf4V3QOIKazrLyQ
z1r0wwJAOTW2sUFgN8NQPH/JA9PN2P3Ix/k+wnN0NhOGfhRbqwT7Agobgox6xVlZ
wmzynJ/n9H++2yW9EjvQE2XZXufKswJAJUt5EqyACRfZEbz473NOWWmXLUsPGuIl
lQ1RlqO9xaV3EDHqtCC1EvkpJhCU3yIW6tSzsVq9E23WzmgHdU8rWQJABB7sXI8H
Irc2454+AaWtEY2VnhPRaqRE4s6v0r0OQHdG+Xcfmj0PSzQyvobESkI4ix3+9DLb
0JNzQR64zWmhOQ==
-----END PRIVATE KEY-----
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
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3KRNwpZIEuEDjx0eBDNBECo5m
ArWYA8YERHsZ+2h+Z2qFIDe2cmtcdZWASHUxOQ4IZqEKFFauzajWci3To6BIigBR
YhaQANHnh277WW//kMyEOqpnhk75V54ZH8+4uAmeY+rc8EspptAHEnHibd91V5oG
gHglFhLnTvXnouPR4QIDAQAB
-----END PUBLIC KEY-----
보안강도 = 비도
1.6 Key Pair 보관 관리
EC2는 키(Key)를 이용한 암호화 기법을 제공합니다. 해당 기법은 퍼블릭/프라이빗 키를 통해 각각 데이터의 암호화 및 해독을 하는 방식으로 여기에 사용되는 키를 ‘Key Pair’ 라고 하며, 해당 암호화 기법을 사용할 시 EC2의 보안성을 향상시킬 수 있으므로 EC2 인스턴스 생성 시 Key Pair 등록을 권장합니다.
또한, Amazon EC2에 사용되는 키는 ‘2048비트 SSH-2 RSA 키’이며, Key Pair는 리전당 최대 5천 개까지 보유할 수 있습니다.
※ Key Pair는 타 사용자가 확인이 가능한 공개된 위치에 보관하게 될 경우 EC2 Instance에 무단으로 접근이 가능해지므로 비인가자가 쉽게 유추 및 접근이 불가능한 장소(Ex. 프라이빗 S3 버킷)에 보관해야 합니다.
1.7 Admin Console 관리자 정책 관리
AWS Cloud 사용을 위해 처음 발급한 계정(AWS 계정 루트 사용자)은 IAM 사용자 계정과 달리 모든 서비스에 접근할 수 있는 최고 관리자 계정입니다.
Cloud 서비스 특성 상 인터넷 연결이 가능한 망에서 계정정보를 입력하여
WEB Console(https://console.aws.amazon.com/ = Management Console)에 접근하게 됩니다.
이는 최고 권한을 보유하고 있는 관리자 계정이 아닌 권한이 조정된 IAM 사용자 계정(꼭 필요한 최소 권한만 사용자 또는 사용자 그룹에 부여된 사용자)을 기본으로 사용해야 보다 안전한 접근이 이뤄질 수 있습니다.
1.8 Admin Console 계정 Access Key 활성화 및 사용주기 관리
Access Key는 AWS의 CLI 도구나 API를 사용할 때(프로그램 방식으로 AWS 리소스를 사용) 필요한 인증수단으로
생성 사용자에 대한 결제정보를 포함한 모든 AWS 서비스의 전체 리소스에 대한 권한을 갖고 있으므로 유출 시 심각한 피해가 발생할 가능성이 높기에
AWS Admin Console Account(AdministratorAccess 권한을 가진 사용자)에 대한 Access Key 삭제를 권장합니다.
💡 Access Key 관리 주기
Key 수명(60일 이내), 비밀번호 수명(60일 이내), 마지막 활동(30일 이내)
1.9 MFA (Multi-Factor Authentication) 설정
TYPE1 지식 패스워드
TYPE2 소유 OTP, 인증서, ...
TYPE3 특징 홍채, 지문, 정맥, 성문, 필기체 서명, ...
root 사용자의 경우
IAM 사용자의 경우
TOTP Authenticator
https://chromewebstore.google.com/detail/totp-authenticator/ibpjepoimpcdofeoalokgpjafnjonkpc?hl=ko
entity already exists 오류가 발생하는 경우
https://repost.aws/knowledge-center/mfa-iam-entity-error
SSO (Single-Sign-On (단일화 인증))
→ 어느 한 곳에 로그인을 하면 그 이후부터는 별도의 로그인 과정을 거치지 않고 해당 시스템을 사용할 수 있도록 도와주는 것
→ SSO를 위해서는 인증을 별도의 인증 서버를 거쳐 진행
1.10 AWS 계정 패스워드 정책 관리
AWS Admin Console Account 계정 및 IAM 사용자 계정의 암호 설정 시 일반적으로 유추하기 쉬운 암호를 설정하는 경우 비 인가된 사용자가 해당 계정을 획득하여 접근 가능성이 존재합니다.
https://www.kisa.or.kr/2060305/form?postSeq=14&lang_type=KO#fnPostAttachDownload
패스워드는 아래의 4가지 문자 종류 중 2종류 이상을 조합하여 최소 10자리 이상 또는 3종류 이상을 조합하여 최소 8자리 이상의 길이로 구성
※ 영문 대문자(26개), 영문 소문자(26개), 숫자(10개), 특수문자(32개)
1.11 EKS 사용자 관리
EKS = Elastic Kubernetes Service
기본적으로 AWS 계정은 리소스에 대한 접근을 허용하는 최소한의 사용자 수와 권한으로 관리되어야 합니다. AWS에서는 IAM 사용자에게 EKS Cluster에 대한 액세스 권한을 부여해야 하는 경우 특정 쿠버네티스 RBAC 그룹에 매핑되는 사용자의 “aws-auth” ConfigMap을 제공하며 ConfigMap(설정 정보를 담아두는 쿠버네티스 리소스)은 초기에는 노드를 Cluster에 연결 목적으로 만들어졌으나 IAM 보안 주체에 역할 기반 액세스 제어(RBAC) 액세스를 추가하여 사용할 수도 있습니다.
동작 방식으로는 사용자 ID가 AWS IAM 서비스에 의해 인증되면 kube-apiserver는 'kubesystem' 네임스페이스에서 aws-auth ConfigMap을 읽어 사용자와 연결할 RBAC 그룹을 결정합니다.
ConfigMap 사용 시 참고 사항으로는 Amazon EKS Cluster를 생성할 경우 Cluster를 생성하는 IAM 보안 주체에게는 Amazon EKS 제어 영역의 Cluster 역할 기반 액세스 제어(RBAC) 구성에 “system:masters” 권한이 자동으로 부여되며 이 액세스는 제거할 수 없으며 “aws-auth” ConfigMap을 통해 관리되지 않습니다. 따라서 전용 IAM 역할로 Cluster를 생성하고 정기적으로 감사하는 것이 좋습니다. 또한, 이 역할을 통해 Cluster에서 일반적인 작업을 수행하는 데 사용되어서는 안 됩니다.
※ aws-auth ConfigMap 변경 시에는 잘못된 형식의 aws-auth 컨피그맵으로 인해 Cluster에 대한 접근 권한을 잃을 수 있어 ConfigMap을 변경해야 하는 경우 도구(eksctl, keikoproj의 aws-auth, AWS IAM Authenticator CLI)를 사용해야합니다.
https://kubernetes.io/ko/docs/concepts/overview/components/
애플리케이션이 다양한 환경에서 원활하게 돌아갈 수 있도록 하는 기술
→ 가상화
가상화는 운영체제 기술이 포함되어 있어야 하기 때문에 무겁고, 그것을 네트워크를 통해 전달해서 실행하는 것이 어렵다는 단점 존재
→ 이것을 해결하기 위해 나온 기술이 도커(Docker)라는 컨테이너 기술
💡 도커는 컨테이너 어플리케이션을 만들고, 배포하고, 사용할 수 있도록 도와주는 역할
도커를 이용하여 내가 만든 어플리케이션을 쉽고, 빠르고, 저렴하게 네트워크를 통해 전달해서 실행하는 것이 가능
→ 이 어플리케이션을 실행하는 환경이 클라우드 환경
컨테이너 어플리케이션
→ 어플리케이션이 실행되는데 필요로 하는 실행 환경과 어플리케이션을 하나로 묶어서 배포해주는 형태
컨테이너 어플리케이션과 가상화의 차이점
→ 가상화와 달리 컨테이너 어플리케이션은 운영체제 부분이 없고 필요로 하는 운영체제 기능들은 호스트 머신에서 빌려와서 사용
컨테이너 어플리케이션을 클라우드 같은 분산 네트워크 환경에서 실행하려고 할 경우, 대표되는 노드 쪽으로 명령어를 전달하고 명령어를 받은 노드는 나머지 노드들에게 이 명령어를 전달해 실행하는 구조
→ 이런 시스템의 묶음을 '클러스터'라 지칭
클러스터를 만들고 클러스터링을 하고 클러스터의 상태를 감시·관리하고 클러스터에 내가 만든 어플리케이션을 배포·실행·관리해주는 도구
→ 오케스트레이션 도구
→ 오케스트레이션 도구의 대표적 예시가 쿠버네티스(Kubernetes)
EKS는 클러스터 내에 노드들을 만들고 관리해주는 역할 담당
1.12 EKS 서비스 어카운트 관리
서비스 어카운트는 파드(pod, 쿠버네티스에서 사용하는 가장 작은 단위로 하나 이상의 컨테이너 어플리케이션을 묶어서 실행하는 단위)에 쿠버네티스 RBAC 역할을 할당할 수 있는 특수한 유형의 개체이며 Cluster 내의 각 네임스페이스에 기본 서비스 어카운트가 자동으로 생성됩니다.
특정 서비스 어카운트를 참조하지 않고 네임스페이스에 파드를 배포하면, 해당 네임스페이스의 파드에 자동으로 할당되고 서비스 어카운트의(JWT) 토큰은 특정 경로의 볼륨으로 파드에 마운트됩니다.
애플리케이션이 Kubernetes API를 호출할 필요가 없는 경우 애플리케이션의 PodSpec에서 automountServiceAccountToken 속성을 false로 설정하거나 각 네임스페이스의 기본 서비스 어카운트를 패치하여 더 이상 파드에 자동으로 마운트되지 않도록 해야 합니다.
1.13 EKS 불필요한 익명 접근 관리
클라우드 환경 내에서는 모든 API 및 리소스 작업 시에 대해 익명 사용자의 접근을 비활성화하여 이용해야 합니다.
