Elastic Compute Service (ECS) インスタンスを作成するときは、Secure Shell (SSH) キーペアなどの新しい個別の認証情報を使用します。カスタムイメージに存在する可能性のある事前設定されたログイン資格情報の使用は避けてください。
セキュリティリスク
カスタムイメージから新しい ECS インスタンスを作成すると、新しいインスタンスはそのイメージから事前設定されたログインパスワードまたは SSH キーを継承します。パブリックイメージにはデフォルトのパスワードは含まれていません。これらの資格情報は、イメージ作成者の便宜のため、または初期のユーザーテストのために設定されることが多いですが、セキュリティリスクをもたらします:
制御されていない資格情報の公開: カスタムイメージはさまざまなソースから提供されます。組み込みのデフォルトパスワードまたはキーが複数のユーザーに配布されている可能性があります。パブリックコードリポジトリや技術フォーラムで誤って公開されることさえあります。攻撃者は常にクラウドプラットフォームをスキャンし、これらの既知のパublic 資格情報を使用してログインしようとします。成功した場合、サーバーを完全に制御できるようになります。
バイパスされたセキュリティ対策: 攻撃者がデフォルトの資格情報を入手すると、他のすべてのセキュリティ対策をバイパスしてサーバーに直接ログインできます。
ベストプラクティス
カスタムイメージを作成するときは、事前設定されたパスワードまたは SSH キーを削除して、それらが公開されないようにします。
すべてのユーザーのパスワードを削除します (
passwd -d <username>)。/root/.ssh/authorized_keysファイルと他のユーザーの `authorized_keys` ファイルが空であることを確認します。bash 履歴をクリアします (
history -c && history -w)。
カスタムイメージからインスタンスを作成するときは、イメージから事前設定されたパスワードを使用しないでください。
この操作は、root または ecs-user のログイン資格情報 (パスワードまたはキーペア) を再構成します。他のユーザーのログイン資格情報はクリアされません。他のユーザーのログイン資格情報をクリアする方法の詳細については、「問題の修正」セクションの手順をご参照ください。
Linux インスタンス
カスタムイメージからインスタンスを作成するときは、イメージから事前設定されたパスワードを使用しないでください。代わりにキーペアを使用します。
コンソール
カスタムイメージからインスタンスを作成する場合、[イメージの事前設定されたパスワードを使用] を選択しないでください。代わりに、[キーペア] を使用します。
API
RunInstances または CreateInstance 操作を呼び出してインスタンスを作成するときは、
PasswordInheritパラメーターをfalseに設定します。Windows インスタンス
カスタムイメージからインスタンスを作成する場合、[イメージの事前設定されたパスワードを使用] を選択しないでください。代わりに、強力なカスタムパスワードを設定します。キーペアはサポートされていません。
コンプライアンス機能
チェック: 非準拠インスタンスのチェック
Workbench を使用して Linux インスタンスにログインし、チェックを実行します。
不審なユーザーアカウントのチェック:
/etc/passwdファイルを表示して、作成していない、またはデフォルトのシステムユーザーではない不明なユーザーがいないか確認します。cat /etc/passwdSSH 認定公開鍵のチェック: 重要なシステムロケーションにある
authorized_keysファイルをチェックして、パスワードなしのログイン用に構成されている公開鍵がないか確認します。# root ユーザーの認定公開鍵をチェック cat /root/.ssh/authorized_keys # 'admin' などの他のユーザーの認定公開鍵をチェック cat /home/admin/.ssh/authorized_keysファイル内の公開鍵を注意深く確認してください。それらがすべて現在使用している秘密鍵に対応していることを確認してください。不審な、または認識できない公開鍵はすぐに削除してください。
ブロック: 事前設定されたイメージパスワードを使用するインスタンス作成の防止
Resource Access Management (RAM) ポリシーを組織またはアカウントレベルで使用して、事前設定されたイメージパスワードを使用するインスタンスの作成を事前にブロックします。
エンタープライズユーザーの場合:
Alibaba Cloud アカウントで リソースディレクトリコンソールにログインします。左側のナビゲーションウィンドウで、[コントロールポリシー] をクリックします。次に、カスタムポリシーを作成し、次の JSON コンテンツを貼り付けます。
このポリシーは、インスタンスの作成時またはシステムディスクの交換時にイメージからデフォルトのパスワードを継承する権限を拒否します。
{ "Version": "1", "Statement": [ { "Action": [ "ecs:RunInstances", "ecs:CreateInstance", "ecs:ReplaceSystemDisk" ], "Resource": "*", "Condition": { "Bool": { "ecs:PasswordInherit": [ "true" ] } }, "Effect": "Deny" } ] }リソースディレクトリで、適切なノードを選択してポリシーをアタッチします。ポリシーは、そのノード配下のすべてのアカウントの操作をブロックします。
個人ユーザーの場合:
Alibaba Cloud アカウントで RAM コンソールにログインします。左側のナビゲーションウィンドウで [ポリシー] をクリックし、上記と同じ内容を含むカスタムポリシーを作成します。
ポリシーを RAM ユーザー、RAM ユーザーグループ、または RAM ロールにアタッチします。詳細については、「ポリシーを使用した権限の付与」をご参照ください。
問題の修正: 事前設定されたイメージパスワードを持つインスタンスからのリスクを修正
新しいログイン資格情報の設定
Linux インスタンス: 新しいキーペアのアタッチ
Windows インスタンス: パスワードのリセット
イメージから元の事前設定された資格情報をクリアする (Linux)
アタッチした新しいキーペアまたは新しいパスワードを使用して ECS インスタンスにログインします。
古い公開鍵の削除: すべての
authorized_keysファイルからすべての古い公開鍵を注意深くチェックしてクリアします。# root ユーザーの authorized_keys ファイルを編集し、不要な公開鍵をすべて削除します vi /root/.ssh/authorized_keys # 他のすべてのユーザーに対して同じ操作を実行します vi /home/<username>/.ssh/authorized_keysパスワードベースのログインを無効にする: キーペアで正常にログインできることを確認したら、SSH サービス構成を変更して、パスワードベースのログインを完全に無効にします。キーペアベースのログインのみを許可します。
# 1. SSH 構成ファイルを編集します sudo vi /etc/ssh/sshd_config # 2. 次の行を見つけて変更します PasswordAuthentication no PubkeyAuthentication yes # 3. SSH サービスを再起動して構成を有効にします sudo systemctl restart sshd
不要なシステムユーザーとファイルのクリーンアップ
/etc/passwdおよび/etc/shadowファイルを確認します。イメージ作成プロセスから残された不要なユーザーアカウントを削除します。また、古いパスワードやキーなどの機密情報を含む可能性のある一時ファイルやスクリプトを確認して削除します。