공유 Linux AMI 만들기 권장 사항

공유 Linux AMI 만들기 권장 사항 (Recommendations for creating shared Linux AMIs)

아래 지침을 사용하면 만들고 있는 AMI의 공격 표면(attack surface)을 줄이고 신뢰성을 높일 수 있어요.

출처: 문서

본문

중요 어떤 보안 지침 목록도 완전할 수는 없어요. 공유 AMI를 신중하게 만들고, 어디에서 민감한 데이터가 노출될 수 있는지 시간을 들여 생각해 보세요.

AWS Marketplace용 AMI를 만드는 중이라면, 지침·정책·모범 사례는 AWS Marketplace Seller Guide의 AMI 빌드 모범 사례를 참고하세요.

루트 사용자의 비밀번호 기반 원격 로그인 비활성화 (Disable password-based remote logins for the root user)

공개 AMI에 고정된 루트 비밀번호를 사용하는 것은 빠르게 알려질 수 있는 보안 위험이에요. 사용자가 첫 로그인 후 비밀번호를 바꾸도록 의존하는 것조차 잠재적인 악용의 여지를 남겨요.

이 문제를 해결하려면 루트 사용자의 비밀번호 기반 원격 로그인을 비활성화해요.

루트 사용자의 비밀번호 기반 원격 로그인 비활성화하기

텍스트 편집기로 /etc/ssh/sshd_config 파일을 열고 다음 줄을 찾아요: #PermitRootLogin yes
그 줄을 다음으로 바꿔요: PermitRootLogin without-password

이 구성 파일의 위치는 배포판에 따라, 또는 OpenSSH를 실행하지 않는 경우에는 다를 수 있어요. 그렇다면 관련 문서를 참고하세요.

로컬 루트 접근 비활성화 (Disable local root access)

공유 AMI를 다룰 때는 직접 루트 로그인을 비활성화하는 것이 모범 사례예요. 이렇게 하려면 실행 중인 인스턴스에 로그인해 다음 명령을 실행해요.

[ec2-user ~]$ sudo passwd -l root

참고 이 명령은 sudo 사용에는 영향을 주지 않아요.

SSH 호스트 키 쌍 제거 (Remove SSH host key pairs)

공개 AMI에서 파생된 AMI를 공유할 계획이라면 /etc/ssh에 있는 기존 SSH 호스트 키 쌍을 제거해요. 이렇게 하면 누군가 여러분의 AMI로 인스턴스를 시작할 때 SSH가 새롭고 고유한 SSH 키 쌍을 생성하도록 강제해서, 보안이 향상되고 "중간자(man-in-the-middle)" 공격 가능성이 줄어들어요.

시스템에 존재하는 다음 키 파일을 모두 제거해요.

ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_key
ssh_host_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub
ssh_host_ecdsa_key
ssh_host_ecdsa_key.pub
ssh_host_ed25519_key
ssh_host_ed25519_key.pub

다음 명령으로 이 파일들을 안전하게 제거할 수 있어요.

[ec2-user ~]$ sudo shred -u /etc/ssh/*_key /etc/ssh/*_key.pub

경고 shred 같은 안전 삭제 유틸리티는 저장 매체에서 파일의 모든 복사본을 제거하지 못할 수 있어요. 파일의 숨겨진 복사본은 저널링 파일 시스템(Amazon Linux 기본인 ext4 포함), 스냅샷, 백업, RAID, 임시 캐싱에 의해 만들어질 수 있어요. 자세한 내용은 shred 문서를 참고하세요.

중요 공개 AMI에서 기존 SSH 호스트 키 쌍 제거를 잊으면, 정기 감사 프로세스가 잠재적 보안 위험을 여러분과 여러분의 AMI로 인스턴스를 실행 중인 모든 고객에게 알려요. 짧은 유예 기간 후에 AMI를 프라이빗으로 표시해요.

공개 키 자격 증명 설치 (Install public key credentials)

비밀번호로 로그인하지 못하도록 AMI를 구성한 후에는 사용자가 다른 메커니즘으로 로그인할 수 있도록 해야 해요.

Amazon EC2는 인스턴스를 시작할 때 사용자가 공개-개인 키 쌍 이름을 지정할 수 있게 해줘요. RunInstances API 호출(또는 명령줄 API 도구)에 유효한 키 쌍 이름이 제공되면, 공개 키(CreateKeyPair 또는 ImportKeyPair 호출 후 Amazon EC2가 서버에 보관하는 키 쌍 부분)는 인스턴스 메타데이터에 대한 HTTP 쿼리를 통해 인스턴스에서 사용할 수 있게 돼요.

SSH로 로그인하려면 AMI가 부팅 시 키 값을 검색해서 /root/.ssh/authorized_keys(또는 AMI의 다른 사용자 계정에 해당하는 위치)에 추가해야 해요. 사용자는 키 쌍으로 AMI 인스턴스를 시작하고 루트 비밀번호 없이 로그인할 수 있어요.

Amazon Linux와 Ubuntu를 포함한 많은 배포판은 cloud-init 패키지를 사용해 구성된 사용자에게 공개 키 자격 증명을 주입해요. 배포판이 cloud-init를 지원하지 않는다면 다음 코드를 시스템 시작 스크립트(예: /etc/rc.local)에 추가해서 시작 시 지정한 루트 사용자의 공개 키를 가져올 수 있어요.

참고 다음 예시에서 IP 주소 http://169.254.169.254/는 링크-로컬(link-local) 주소로, 인스턴스에서만 유효해요.

IMDSv2

if [ ! -d /root/.ssh ] ; then
    mkdir -p /root/.ssh
    chmod 700 /root/.ssh
fi
# Fetch public key using HTTP
TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key > /tmp/my-key
if [ $? -eq 0 ] ; then
    cat /tmp/my-key >> /root/.ssh/authorized_keys
    chmod 700 /root/.ssh/authorized_keys
    rm /tmp/my-key
fi

IMDSv1

if [ ! -d /root/.ssh ] ; then
    mkdir -p /root/.ssh
    chmod 700 /root/.ssh
fi
# Fetch public key using HTTP
curl http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key > /tmp/my-key
if [ $? -eq 0 ] ; then
    cat /tmp/my-key >> /root/.ssh/authorized_keys
    chmod 700 /root/.ssh/authorized_keys
    rm /tmp/my-key
fi

이 코드는 어떤 사용자에게든 적용할 수 있어요. 루트 사용자로 제한할 필요는 없어요.

참고 이 AMI를 기반으로 인스턴스를 리번들(rebundle)하면 시작할 때 사용된 키도 포함돼요. 키가 포함되지 않게 하려면 authorized_keys 파일을 비우거나(또는 삭제) 리번들링에서 이 파일을 제외해야 해요.

sshd DNS 검사 비활성화 (선택 사항) (Disable sshd DNS checks (optional))

sshd DNS 검사를 비활성화하면 sshd 보안이 약간 약해져요. 하지만 DNS 확인이 실패해도 SSH 로그인은 여전히 동작해요. sshd 검사를 비활성화하지 않으면 DNS 확인 실패 시 모든 로그인이 차단돼요.

sshd DNS 검사 비활성화하기

텍스트 편집기로 /etc/ssh/sshd_config 파일을 열고 다음 줄을 찾아요: #UseDNS yes
그 줄을 다음으로 바꿔요: UseDNS no

참고 이 구성 파일의 위치는 배포판에 따라, 또는 OpenSSH를 실행하지 않는 경우에는 다를 수 있어요. 그렇다면 관련 문서를 참고하세요.

민감한 데이터 제거 (Remove sensitive data)

공유하려는 AMI에 민감한 데이터나 소프트웨어를 저장하지 않는 것을 권장해요. 공유 AMI를 시작한 사용자는 이를 리번들해서 자신의 AMI로 등록할 수 있을지도 몰라요. 간과하기 쉬운 보안 위험을 피하기 위해 다음 지침을 따라요.

번들에 포함하고 싶지 않은 비밀 정보가 있는 디렉터리와 하위 디렉터리를 건너뛰도록 ec2-bundle-vol의 --exclude 디렉터리 옵션을 사용하는 것을 권장해요. 특히 이미지를 번들할 때 사용자가 소유한 모든 SSH 공개/개인 키 쌍과 SSH authorized_keys 파일을 제외해요. Amazon 공개 AMI는 루트 사용자의 경우 /root/.ssh에, 일반 사용자의 경우 /home/user_name/.ssh/에 이를 저장해요. 자세한 내용은 ec2-bundle-vol을 참고하세요.
번들하기 전에 항상 셸 히스토리를 삭제해요. 같은 AMI에서 번들 업로드를 두 번 이상 시도하면 셸 히스토리에 접근 키가 포함돼요. 다음 예시는 인스턴스 내에서 번들하기 전에 실행해야 할 마지막 명령이에요.

[ec2-user ~]$ shred -u ~/.*history

경고 위 경고에서 설명한 shred의 한계가 여기에도 적용돼요. bash는 종료 시 현재 세션의 히스토리를 디스크에 쓴다는 점을 기억하세요. ~/.bash_history를 삭제한 후 인스턴스에서 로그아웃했다가 다시 로그인하면, ~/.bash_history가 다시 생성되어 이전 세션에서 실행한 모든 명령이 포함되어 있는 걸 발견할 거예요. bash 외의 다른 프로그램도 히스토리를 디스크에 써요. 조심하고 불필요한 dot-file과 dot-directory를 제거하거나 제외해요.

실행 중인 인스턴스를 번들하려면 프라이빗 키와 X.509 인증서가 필요해요. 이 자격 증명을 번들에 포함되지 않는 위치(예: 인스턴스 스토어)에 두세요.

공유 Linux AMI 만들기 권장 사항