공유 Linux AMI 지침 - Amazon Elastic Compute Cloud 
 AWS Documentation » Amazon EC 2 » User Guide for Linux Instances » Amazon 머신 이미지 ( AMI ) » 공유 AMI » 공유 Linux AMI 지침 
 AMI 의 안정 성 을 높이 고 공격 대상 영역 을 최소 화 하 려면 다음 지침 을 사용 하 십시오 . 
 어떤 보안 지침 도 포괄 적 일 수 는 없 습니다 . 공유 AMI 를 구축 할 때 는 민감 한 데이터 의 유출 가능 성 에 특히 유의 하 고 , 충분 한 시간 을 할애 하 여 검토 하 십시오 . 
 부팅 시 AMI 도구 업데이트 
 루트 사용 자 의 암호 방식 원격 로그인 비활성 화 
 로컬 루트 액세스 비활성 화 
 SSH 호스트 키 페어 삭제 
 퍼블릭 키 자격 증명 프로그램 설치 
 sshd DNS 확인 비활성 화 ( 선택 사항 ) 
 AWS Marketplace 용 AMI 를 구축 하 는 경우 에 는 Building AMIs for AWS Marketplace 의 지침 과 정책 , 모범 사례 를 참조 하 십시오 . 
 안전 한 AMI 공유 에 대한 추가 내용 은 다음 을 참조 하 십시오 . 
 안전 한 방식 으로 퍼블릭 AMI 를 공유 하 고 사용 하 는 방법 
 인 스턴스 스토어 지원 AMI 의 경우 , AMI 부팅 시 Amazon EC 2 AMI 생성 도구 를 다운로드 받 고 업그레이드 하 는 것 을 권장 합니다 . 이 를 통해 공유 AMI 를 기반 으로 한 새 AMI 에서 최신 AMI 도구 를 사용 할 수 있 습니다 . 
 Amazon Linux 는 다음 을 / etc / rc . local 에 추가 합니다 . 
 # Update the Amazon EC 2 AMI tools 
 echo " + Updating EC 2 AMI tools " 
 echo " + Updated EC 2 AMI tools " 
 이 방법 을 사용 하 여 이미지 이 다른 소트 트 웨어 를 자동 으로 업데이트 합니다 . 
 자동 업데이트 할 소프트웨어 를 결정 할 때 는 업데이트 로 인해 고객 이 비용 을 부담 하 게 되 는 WAN 트래픽 수준 과 업데이트 로 AMI 의 다른 소프트웨어 오류 가 발생 할 위험 성 을 고려 해야 합니다 . 
 기타 배포 의 경우 에 는 AMI 도구 를 항상 최신 으로 유지 합니다 . 
 퍼블릭 AMI 에 대하 여 고정 루트 암호 를 사용 하 면 보 안 위험 을 촉진 하 는 계기 가 될 수 있 습니다 . 고객 에게 최초 로그인 시 암호 변경 을 알린다 해도 여기 에 만 의존 한다면 어느 정도 의 오용 가능 성 은 여전히 존재 합니다 . 
 이런 문제 를 해결 하 려면 루트 사용 자 의 암호 방식 원격 로그인 을 비 활성 화 합니다 . 
 텍스트 편집기 로 / etc / ssh / sshd _ config 파일 을 열 고 다음 열 을 검색 합니다 . 
 해당 열 을 다음 과 같이 변경 합니다 . 
 이 구성 파일 의 저장 위치 는 배포 에 따라서 혹은 OpenSSH 를 실행 하 지 않 는 경우 달라질 수 있 습니다 . 이 경우 에 는 관련 문서 를 참조 하 십시오 . 
 공유 AMI 를 사용 할 때 는 직접 루트 로그인 을 비 활성 화 하 는 것 이 모범 사례 입니다 . 이렇게 하 려면 실행 중 인 인 스턴스 에 로그인 하 여 다음 명령 을 사용 합니다 . 
 [ ec 2 - user ~]$ sudo passwd - l root 
 이 명령 은 sudo 사용 에 는 영향 을 주 지 않 습니다 . 
 퍼블릭 AMI 에서 유래 된 AMI 를 공유 할 계획 이 라면 / etc / ssh 에 저장 된 현재 SSH 호스트 키 페어 를 삭제 하 십시오 . 이 작업 은 다른 사용 자 가 이 AMI 를 사용 해 인 스턴스 를 시작 할 때 SSH 에서 반드시 새로운 고유 SSH 키 페어 를 생성 하 도록 하 기 때문 에 " 중간자 공격 " 가능 성 을 낮추 고 보안 을 향상 시켜 줍니다 . 
 시스템 에서 다음 의 키 파일 을 모두 제거 합니다 . 
 이런 파일 은 다음 명령 을 실행 하 여 안 전하 게 제거 할 수 있 습니다 . 
 [ ec 2 - user ~]$ sudo shred - u / etc / ssh / *_ key / etc / ssh / *_ key . pub 
 shred 와 같 은 보안 삭제 유틸리티 는 스토리지 미디어 에서 파일 의 사본 을 모두 제거 하 지 못할 수 있 습니다 . 파일 시스템 ( Amazon Linux default ext 4 포함 ) , 스냅샷 , 백업 , RAID 및 임시 캐 싱 을 저널 링 하 여 파일 의 숨겨진 사본 이 생성 될 수 있 습니다 . 자세 한 내용 은 shred 문서 를 참조 하 십시오 . 
 퍼블릭 AMI 의 현재 SSH 호스트 키 페어 를 제거 하 지 않 은 경우 , 기본 적 인 자체 감사 과정 에서 소유자 를 비롯 해 해당 AMI 를 사용 해 인 스턴스 를 실행 하 는 모든 사용자 에게 잠재 적 인 보안 위험 을 알리 는 메시지 가 표시 됩니다 . 이 AMI 는 단기 적 인 유예 기간 후 프라이빗 상태 로 변경 됩니다 . 
 암호 를 사용 한 AMI 로그인 을 비 활성 화 했 다면 이제 다른 방식 으로 사용 자 가 로그인 할 수 있 도록 해야 합니다 . 
 Amazon EC 2 에서 는 인 스턴스 를 시작 할 때 사용 자 가 퍼블릭 / 프라이빗 키 페어 이름 을 설정 하 는 것 을 허용 합니다 . 유효 한 키 페어 이름 이 RunInstances API 호출 ( 또는 명령 출 API 도구 ) 로 전송 되 면 , 퍼블릭 키 ( Amazon EC 2 에서 CreateKeyPair 또는 ImportKeyPair 로 의 호출 이 이루어진 후 에 서버 에 저장 하 는 키 페어 의 일부 ) 를 인 스턴스 메타데이터 에 대한 HTTP 쿼리 를 통해 인 스턴스 에서 사용 할 수 있 게 됩니다 . 
 SSH 을 통해 로그인 하 려면 AMI 에서 반드시 부팅 시 키 값 을 회수 하 고 이 값 을 / root / . ssh / authorized _ keys 에 ( 또는 AMI 상 의 다른 사용자 계정 의 값 ) 첨부 해야 합니다 . 사용자 는 루트 암호 없이 키 페어 를 사용 하 여 AMI 의 인 스턴스 를 실행 할 수 있 습니다 . 
 Amazon Linux 및 Ubuntu 를 포함 한 대부분 의 배포판 에서 는 지정 된 사용자 에 대한 퍼블릭 키 자격 증명 을 첨가 할 때 cloud - init 패키지 를 사용 합니다 . 사용 하 는 배포판 에서 cloud - init 를 지원 하 지 않 는 경우 , 시스템 시작 스크립트 ( 예 : / etc / rc . local ) 에 다음 코드 를 추가 하 여 시작 시 루트 사용자 에 대해 지정 한 퍼블릭 키 를 가져오 도록 설정 할 수 있 습니다 . 
 curl http : / / 169 . 254 . 169 . 254 / latest / meta - data / public - keys / 0 / openssh - key > / tmp / my - key 
 이 작업 은 어떤 사용자 계정 에 나 적용 할 수 있 으며 , root 로 제한 할 필요 가 없 습니다 . 
 이 AMI 를 기반 으로 인 스턴스 를 다시 번들 링 하 면 시작 했 을 때 사용 했 던 키 가 포함 됩니다 . 키 가 포함 되 는 것 을 방지 하 려면 authorized _ keys 파일 의 내용 을 지우 거나 파일 을 삭제 하 는 방법 , 또는 재번 들 링 시 파일 을 포함 제외 해야 합니다 . 
 sshd DNS 확인 을 비 활성 화 하 면 sshd 보안 성 은 약간 저하 됩니다 . 하 지만 DNS 확인 이 실패 했 을 때 에 도 SSH 로그인 이 가능 하 게 해 줍니다 . sshd 확인 을 비 활성 화 하 면 DNS 확인 오류 시 모든 로그인 이 금지 됩니다 . 
 sshd DNS 확인 비활성 화 
 AMI 는 계정 ID 로 표시 되 기 때문 에 공유 AMI 제공 자 를 간편 하 게 확인 할 수 있 는 방법 은 현재 존재 하 지 않 습니다 . 
 Amazon 에서 는 Amazon EC 2 forum 에 AMI 설명 과 AMI ID 를 게시 하 는 것 을 권장 합니다 . 새로운 공유 AMI 에 흥미 를 가지 고 시도 하 려는 사용자 에게 유용 한 중심 자료 소 를 제공 하 기 때문 입니다 . 
 먼저 섹션 에서 는 안 전하 고 보안 된 공유 AMI 를 만들 고 사용 자 시작 권한 을 설정 하 는 방법 에 대해 알아보 았 습니다 . 이 섹션 에서 는 공유 한 AMI 를 사용 하 는 다른 사용자 로부터 보안 을 유지 하 는 방법 을 안내 합니다 . 
 공유 하 는 AMI 에 는 민감 한 데이터 나 소프트웨어 를 포함 하 지 않 는 것 이 권장 됩니다 . 공유 AMI 를 시작 하 는 사용 자 가 이런 AMI 를 재번 들 링 하 여 본인 소유 로 등록 할 수 있 기 때문 입니다 . 다음 지침 에 따라 그냥 지나치 기 쉬운 보안 위험 에 대처 하 십시오 . 
 ec 2 - bundle - vol 에서 -- exclude directory 옵션 을 사용 해 번들 에 포함 하 지 않 아야 할 보안 정보 가 담긴 디렉터리 나 하위 디렉터리 를 선택 하 지 않 는 방법 을 권장 합니다 . 특히 , 이미지 를 번들 링 할 때 모든 사용자 소유 SSH 퍼블릭 / 프라이빗 키 페어 와 SSH authorized _ keys 파일 을 제외 하 십시오 . Amazon 퍼블릭 AMI 는 이 들 파일 을 루트 계정 의 경우 / root / . ssh 에 저장 하 고 일반 사용 자 계정 의 경우 / home / user _ name / . ssh / 에 저장 합니다 . 자세 한 내용 은 ec 2 - bundle - vol 단원 을 참조 하 십시오 . 
 번들 링 전 에 는 항상 셸 기록 을 삭제 합니다 . 동일 한 AMI 로 하나 이상 의 번들 을 업로드 하 려고 시도 하 면 셸 기록 에 보안 액세스 키 가 포함 됩니다 . 다음 명령 은 인 스턴스 내 에서 번들 링 을 실시 하 기 전 마지막 단계 로 실행 해야 합니다 . 
 [ ec 2 - user ~]$ shred - u ~/.* history 
 위 경고 에서 설명 한 shred 의 제한 은 여기 에 도 적용 됩니다 . 
 bash 는 종료 시점 에서 현재 세션 의 이력 을 디스크 에 기록 한다는 점 을 유의 하 십시오 . ~/. bash _ history 를 삭제 한 후 인 스턴스 에서 로그아웃 했 다가 다시 로그인 할 경우 ~/. bash _ history 가 다시 생성 되 고 이전 세션 에서 실행 한 모든 명령 이 포함 되 어 있 는 것 을 알 수 있 습니다 . 
 bash 이외 의 다른 프로그램 도 디스크 에 이력 을 기록 하 므로 불 필요 한 DOT 파일 및 DOT 디렉터리 를 삭제 또는 제외 하 도록 주의 하 십시오 . 
 실행 중 인 인 스턴스 를 번들 링 하 려면 프라이빗 키 와 X . 509 인증서 가 요구 됩니다 . 이런 정보 와 다른 자격 증명 은 번들 링 에 포함 되 지 않 은 장소 ( 예 : 인 스턴스 스토어 ) 에 따로 보관 하 십시오 .