# 共有 Linux AMI の作成に関する推奨事項
攻撃対象領域を縮小し、作成する AMI の信頼性を向上させるためには、次のガイドラインを使用します。
**重要**
セキュリティのガイドラインのリストは、いずれも完全ではありません。共有 AMI を注意深く作成し、機密データが漏洩される可能性について十分考慮してください。
**Topics**
+ [ルートユーザーのパスワードベースのリモートログインを無効にする](#public-amis-disable-password-logins-for-root)
+ [ローカルルートアクセスを無効にする](#restrict-root-access)
+ [SSH ホストキーペアの削除](#remove-ssh-host-key-pairs)
+ [パブリックキー認証情報のインストール](#public-amis-install-credentials)
+ [sshd DNS チェックの無効化 (任意)](#public-amis-disable-ssh-dns-lookups)
+ [機密データを削除する](#public-amis-protect-yourself)
AWS Marketplace の AMI を構築する場合は、*AWS Marketplace 販売者ガイド*の「[AMI 構築のベストプラクティス](https://docs.aws.amazon.com/marketplace/latest/userguide/best-practices-for-building-your-amis.html)」で、ガイドライン、ポリシー、ベストプラクティスをご参照ください。
## ルートユーザーのパスワードベースのリモートログインを無効にする
パブリック AMI に固定のルートパスワードを使用することは、セキュリティの面で危険であり、すぐに知られるおそれがあります。初回ログイン後にパスワードを変更するようにユーザーに依存していますが、変更されるまでの一瞬の間にパスワードが悪用される危険性があります。
この問題を解決するには、ルートユーザーのパスワードベースのリモートログインを無効にします。
**ルートユーザーのパスワードベースのリモートログインを無効にするには**
1. テキストエディタで `/etc/ssh/sshd_config` ファイルを開き、次の行を見つけ出します:
```
#PermitRootLogin yes
```
1. 行を次のように変更します:
```
PermitRootLogin without-password
```
この設定ファイルの場所は、ディストリビューションに応じて、または OpenSSH を実行していない場合は、異なることがあります。このような場合は、関連資料を参照してください。
## ローカルルートアクセスを無効にする
共有 AMI を使用する際のベストプラクティスは、直接ルートログインを無効にすることです。これを行うには、実行中のインスタンスにログインし、次のコマンドを発行します。
```
[ec2-user ~]$ sudo passwd -l root
```
**注記**
このコマンドが `sudo` の使用に影響を及ぼすことはありません。
## SSH ホストキーペアの削除
パブリック AMI から派生した AMI を共有する場合は、`/etc/ssh` にある既存の SSH ホストキーペアを削除します。これにより、他のユーザーがお客様の AMI を使用してインスタンスを起動したときに、SSH は、新しい固有の SSH キーペアを生成するように強制されるため、セキュリティが強化され、「中間者」攻撃の可能性を減らします。
システムにある次のすべてのキーファイルを削除します。
+ ssh\$1host\$1dsa\$1key
+ ssh\$1host\$1dsa\$1key.pub
+ ssh\$1host\$1key
+ ssh\$1host\$1key.pub
+ ssh\$1host\$1rsa\$1key
+ ssh\$1host\$1rsa\$1key.pub
+ ssh\$1host\$1ecdsa\$1key
+ ssh\$1host\$1ecdsa\$1key.pub
+ ssh\$1host\$1ed25519\$1key
+ ssh\$1host\$1ed25519\$1key.pub
次のコマンドを使用して、これらのファイルをすべて確実に削除できます。
```
[ec2-user ~]$ sudo shred -u /etc/ssh/*_key /etc/ssh/*_key.pub
```
**警告**
**shred** などの安全な削除ユーティリティでは、ストレージメディアからファイルのすべてのコピーが削除されない場合があります。ファイルの非表示のコピーは、ジャーナルファイルシステム (Amazon Linux のデフォルト ext4 を含む)、スナップショット、バックアップ、RAID、および一時キャッシュによって作成することができます。詳細については、[shred ドキュメント](https://www.gnu.org/software/coreutils/manual/html_node/shred-invocation.html)を参照してください。
**重要**
パブリック AMI から既存の SSH ホストキーペアを削除することを忘れた場合、ルーチン監査プロセスから、AMI のインスタンスを実行するすべての顧客に向けて、セキュリティ上のリスクがある可能性について通知されます。短い猶予期間の後に、AMI にプライベートのマークが付けられます。
## パブリックキー認証情報のインストール
パスワードを使用したログインを防ぐように AMI を構成したら、ユーザーが別のメカニズムを使用してログインできるようにしておく必要があります。
ユーザーは、Amazon EC2 を使用すると、インスタンスの起動時にパブリックプライベートキーペア名を指定できます。`RunInstances` API 呼び出し (またはコマンドライン API ツール) で有効なキーペア名を指定すると、パブリックキー (`CreateKeyPair` または `ImportKeyPair` の呼び出し後に Amazon EC2 がサーバー上に保持するキーペアの一部) を、インスタンスメタデータに対する HTTP Query を介してインスタンスで使用できるようになります。
SSH を使用してログインするには、AMI が起動時にキー値を取得し、それを `/root/.ssh/authorized_keys` (または AMI 上のその他のユーザーアカウントの同等項目) に付加する必要があります。ユーザーはキーペアを使用して AMI のインスタンスを起動し、ルートパスワードを入力せずにログインできます。
Amazon Linux や Ubuntu を初めとする多くのディストリビューションでは、`cloud-init` パッケージを使用して、設定されたユーザーのパブリックキー認証情報を挿入します。`cloud-init` をサポートしていないディストリビューションの場合は、システムスタートアップスクリプト (例: `/etc/rc.local`) に次のコードを追加して、起動時にルートユーザーに対して指定したパブリックキーを取り込みます。
**注記**
次の例では、IP アドレス http://169.254.169.254/ はリンクローカルアドレスであり、インスタンスからのみ有効です。
------
#### [ 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
```
------
この設定は、あらゆるユーザーに適用できます。`root` ユーザーに限定する必要はありません。
**注記**
この AMI に基づいたインスタンスを再バンドルすると、起動時に使用されたキーが組み込まれます。キーへの組み込みを阻止するには、`authorized_keys` ファイルの を空にする (ファイルを削除する) か、このファイルを再バンドルから除外します。
## sshd DNS チェックの無効化 (任意)
sshd DNS チェックを無効にすると、sshd セキュリティが若干低下します。ただし、DNS の解決策が失敗した場合は、SSH ログインが引き続き機能します。sshd チェックを無効にしなかった場合、DNS の解決策が失敗すると、すべてのログインが阻止されます。
**sshd DNS チェックを無効にするには**
1. テキストエディタで `/etc/ssh/sshd_config` ファイルを開き、次の行を見つけ出します:
```
#UseDNS yes
```
1. 行を次のように変更します:
```
UseDNS no
```
**注記**
この設定ファイルの場所は、ディストリビューションに応じて、または OpenSSH を実行していない場合は、異なることがあります。このような場合は、関連資料を参照してください。
## 機密データを削除する
共有する AMI に、機密性のあるデータやソフトウェアは保管しないことをお勧めします。共有 AMI を起動するユーザーは、それを再バンドルしたり、自分のものとして登録したりできる可能性があります。以下のガイドラインに従って、見落としやすいセキュリティ上のリスクを回避してください:
+ `--exclude directory` で `ec2-bundle-vol` オプションを使用して、バンドル操作に含めたくない機密情報が入っているディレクトリおよびサブディレクトリをスキップすることをお勧めします。特に、イメージをバンドルするときに、すべてのユーザー所有の SSH パブリックキー/プライベートキーペアおよび SSH `authorized_keys` ファイルを除外します。Amazon パブリック AMI で、これらのファイルは、ルートユーザーの場合は `/root/.ssh`、通常のユーザーの場合は `/home/user_name/.ssh/` に配置されています。詳細については、[ec2-bundle-vol](ami-tools-commands.md#ami-bundle-vol) を参照してください。
+ バンドルの前に必ずシェル履歴を削除してください。同じ AMI で複数のバンドルのアップロードを試行すると、シェル履歴にアクセスキーが含まれます。次の例は、インスタンス内からのバンドルの前に実行される最後のコマンドとなる必要があります。
```
[ec2-user ~]$ shred -u ~/.*history
```
**警告**
上記の警告で示した **shred** の制限は、ここにも適用されます。
bash は、終了時に現在のセッション履歴をディスクに書き込むことに注意してください。`~/.bash_history` を削除後にインスタンスをログアウトし、再度ログインすると、`~/.bash_history` が再作成され、前のセッション中に実行されたすべてのコマンドが含まれています。
bash 以外の他のプログラムもディスクに履歴を書き込むため、注意して不要な dot ファイルと dot ディレクトリを削除または除外します。
+ 実行中のインスタンスをバンドルするには、プライベートキーと X.509 証明書が必要です。これらの証明書およびその他の証明書を、バンドルされていない場所 (インスタンスストアなど) に書き込みます。