共有 Linux AMI のガイドライン

攻撃対象領域を縮小し、作成する AMI の信頼性を向上させるためには、次のガイドラインを使用します。

重要

セキュリティのガイドラインのリストは、いずれも完全ではありません。共有 AMI を注意深く作成し、機密データが漏洩される可能性について十分考慮してください。

AWS Marketplace の AMI を構築する場合は、AWS Marketplace 販売者ガイドの「AMI 構築のベストプラクティス」で、ガイドライン、ポリシー、ベストプラクティスをご参照ください。

AMI の安全な共有についての詳細は、次の記事を参照してください。

• パブリック AMI を安全に共有し使用する方法

• パブリック AMI の公開: セキュリティ強化とクリーンアップの要件

使用する前に AMI ツールを更新する

Instance Store-Backed の AMI の場合、使用する前に、AMI で Amazon EC2 AMI 作成ツールをダウンロードして、アップグレードすることをお勧めします。これにより、共有 AMI に基づく新しい AMI に最新の AMI ツールが与えられます。

Amazon Linux 2 では、aws-amitools-ec2 パッケージをインストールし、次のコマンドで PATH に AMI ツールを追加します。Amazon Linux AMI の場合、デフォルトで aws-amitools-ec2 パッケージが既にインストールされています。

[ec2-user ~]$ sudo yum install -y aws-amitools-ec2 && export PATH=$PATH:/opt/aws/bin > /etc/profile.d/aws-amitools-ec2.sh && . /etc/profile.d/aws-amitools-ec2.sh

次のコマンドを使用して AMI ツールをアップグレードします。

[ec2-user ~]$ sudo yum upgrade -y aws-amitools-ec2

他のディストリビューションの場合は、AMI ツールが最新版であることを確認してください。

ルートユーザーのパスワードベースのリモートログインを無効にする

パブリック AMI に固定のルートパスワードを使用することは、セキュリティの面で危険であり、すぐに知られるおそれがあります。初回ログイン後にパスワードを変更するようにユーザーに依存していますが、変更されるまでの一瞬の間にパスワードが悪用される危険性があります。

この問題を解決するには、ルートユーザーのパスワードベースのリモートログインを無効にします。

ルートユーザーのパスワードベースのリモートログインを無効にするには

1. テキストエディタで /etc/ssh/sshd_config ファイルを開き、次の行を見つけ出します:

   #PermitRootLogin yes

2. 行を次のように変更します:

   PermitRootLogin without-password

   この設定ファイルの場所は、ディストリビューションに応じて、または OpenSSH を実行していない場合は、異なることがあります。このような場合は、関連資料を参照してください。

ローカルルートアクセスを無効にする

共有 AMI を使用する際のベストプラクティスは、直接ルートログインを無効にすることです。これを行うには、実行中のインスタンスにログインし、次のコマンドを発行します。

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

注記

このコマンドが sudo の使用に影響を及ぼすことはありません。

SSH ホストキーペアの削除

パブリック AMI から派生した AMI を共有する場合は、/etc/ssh にある既存の SSH ホストキーペアを削除します。これにより、他のユーザーがお客様の AMI を使用してインスタンスを起動したときに、SSH は、新しい固有の SSH キーペアを生成するように強制されるため、セキュリティが強化され、「中間者」攻撃の可能性を減らします。

システムにある次のすべてのキーファイルを削除します。

• 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 にプライベートのマークが付けられます。

パブリックキー認証情報のインストール

パスワードを使用したログインを防ぐように 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

2. 行を次のように変更します:

   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 で複数のバンドルのアップロードを試行すると、シェル履歴にアクセスキーが含まれます。次の例は、インスタンス内からのバンドルの前に実行される最後のコマンドとなる必要があります。

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

  警告

  上記の警告で示した shred の制限は、ここにも適用されます。

  bash は、終了時に現在のセッション履歴をディスクに書き込むことに注意してください。~/.bash_history を削除後にインスタンスをログアウトし、再度ログインすると、~/.bash_history が再作成され、前のセッション中に実行されたすべてのコマンドが含まれています。

  bash 以外の他のプログラムもディスクに履歴を書き込むため、注意して不要な dot ファイルと dot ディレクトリを削除または除外します。

• 実行中のインスタンスをバンドルするには、プライベートキーと X.509 証明書が必要です。これらの証明書およびその他の証明書を、バンドルされていない場所 (インスタンスストアなど) に書き込みます。