翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Session Manager と Amazon EC2 Instance Connect により踏み台ホストにアクセス
作成者：Piotr Chotkowski (AWS) と Witold Kowalik (AWS)
概要
踏み台ホストは、ジャンプボックスと呼ばれることもありますが、外部ネットワークからプライベートネットワークにあるリソースへの単一アクセスポイントを提供するサーバーです。インターネットなどの外部のパブリックネットワークに公開されているサーバーは、不正アクセスによる潜在的なセキュリティリスクをもたらします。これらのサーバーへのアクセスを保護し、制御することは重要です。
このパターンは、「Session Manager」と「Amazon EC2 Instance Connect」により、AWS アカウントにデプロイされた Amazon Elastic Compute Cloud (Amazon EC2) 踏み台に安全に接続する方法を示しています。ステートマネージャーは AWS Systems Manager の機能です。このパターンには次のようなメリットがあります。
デプロイされた踏み台ホストには、パブリックインターネットに公開されているオープンなインバウンドポートはありません。これにより、潜在的なアタックサーフェスが減少します。
長期間のSecure Shell (SSH) キーを AWS アカウントに保存して管理する必要はありません。代わりに、各ユーザーは 踏み台ホストに接続するたびに新しい SSH キーペアを生成します。AWS Identity and Access Management (IAM) ポリシーにより、踏み台ホストへのアクセスを制御するユーザーに AWS 認証情報が添付されています。
対象者
このパターンは、Amazon EC2、Amazon Virtual Private Cloud (VPC) および Hashicorp Terraform の基本知識がある読者を対象としています。
前提条件と制限
前提条件
アクティブな AWS アカウント
AWS CLI 用のセッションマネージャープラグイン、「インストール済み」
「インストール済み
」のテラフォーム CLI Amazon Simple Storage Service (Amazon S3) バケットやAmazon DynamoDB テーブルなどTerraform ステータスを格納するリモートバックエンドとしてのTerraform「ステータス
」の格納 Terraform ステータスにリモートバックエンドを使用する方法の詳細については、「S3 バックエンド 」(Terraform のドキュメント)」を参照してください。S3 バックエンドでリモートステート管理をセットアップするコードサンプルについては、「remote-state-s3-backend 」 (Terraform レジストリ) を参照してください。次の要件に注意してください。 DB インスタンスと S3 バケットが同じ AWS リージョンに存在する必要があります。
DynamoDB テーブルを作成する場合、パーティションキーは
LockID(大文字と小文字を区別)、パーティションキータイプはStringである必要があります。他の設定はすべてデフォルト値のままにしておきます。詳細については、「DynamoDB のドキュメント」の「プライマリキーについて」と「テーブルの作成」を参照してください。
SSH クライアント、インストール済み
制約事項
このパターンは、概念実証 (PoC) として、または今後の開発の基礎となることを目的としています。本稼働環境では、現行の形式を使用しないでください。デプロイする前に、要件とユースケースに合うようにリポジトリ内のサンプルコードを見直してください。
このパターンは、ターゲットの踏み台ホストがオペレーティングシステムとして Amazon Linux 2 を使用していることを前提としています。他の Amazon マシンイメージ (AMI) を使用することもできますが、他のオペレーティングシステムはこのパターンの対象外です。
注記
Amazon Linux 2 のサポートは間もなく終了します。詳細については、「Amazon Linux 2 のFAQs
」を参照してください。 このパターンでは、踏み台ホストは NAT ゲートウェイとインターネットゲートウェイのないプライベートサブネットに配置されます。EC2 Identity and Access Management (IAM) でインスタンスに接続します。インターネットと通信できるようにする特定のネットワーク設定を追加できます。詳細については、「Amazon VPC のドキュメント」の「仮想プライベートクラウド (VPC) を他のネットワークに接続」を参照してください。同様に、「最小特権原則」に従い、明示的に権限を付与しない限り、踏み台ホストは AWS アカウント内の他のリソースにアクセスできません。詳細については、IAM ドキュメントの「リソースベースのポリシー」を参照してください
製品バージョン
AWS CLI バージョン 2
Terraform バージョン 1.3.9
アーキテクチャ
ターゲットテクノロジースタック
シングルパブリックサブネットを持つ VPC
以下の「インターフェイス VPC エンドポイント」：
amazonaws.<region>.ssm— Systems Manager サービスのエンドポイント。amazonaws.<region>.ec2messages— Systems Manager は、このエンドポイントを使用して、SSM Agent から Systems Manager サービスへの呼び出しを行います。amazonaws.<region>.ssmmessages— Session Manager はこのエンドポイントで、安全なデータチャネルを介して EC2 インスタンスに接続します。
Amazon Linux 2 を実行する
t3.nanoEC2 インスタンスを起動します。IAM ロールとインスタンス プロファイル
エンドポイントと EC2 インスタンスの Amazon VPC セキュリティグループとセキュリティグループルール
ターゲットアーキテクチャ
図に示す内容は以下のとおりです。
ユーザーが割り当てられている IAM ロールには、次の操作を実行する権限があります。
EC2 インスタンスの認証、認可と接続
Session Management (IAM) でセッションを開始
ユーザーは Session Manager から SSH セッションを開始します。
Session Manager はユーザーを認証し、関連する IAM ポリシーの権限を検証し、設定を確認し、SSM エージェントにメッセージを送信して双方向接続を開きます。
ユーザーは Amazon EC2 メタデータを介して SSH パブリックキーを踏み台ホストにプッシュします。これは各接続の前に行う必要があります。SSH 公開鍵は 60 秒間使用可能です。
踏み台ホストは、Systems Manager と Amazon EC2 のインターフェイス VPC エンドポイントと通信します。
ユーザーは TLS 1.2 で暗号化された双方向通信チャネルにより、Session Manager を通じて踏み台ホストにアクセスします。
自動化とスケール
このアーキテクチャを自動的にデプロイしまたは拡張するには、次のオプションを使用します。
継続的な統合および継続的な提供 (CI/CD) パイプラインで、アーキテクチャをデプロイできます。
コードを変更して、踏み台ホストのインスタンスタイプを変更できます。
コードを変更して複数の踏み台ホストをデプロイできます。
bastion-host/main.tfファイルのaws_instanceリソースブロックに、countメタ引数を追加します。詳細については、「Terraform のドキュメント」を参照してください。
ツール
AWS サービス
「AWS コマンドラインインターフェイス (AWS CLI)」は、オープンソースのツールであり、コマンドラインシェルのコマンドを使用して AWS サービスとやり取りすることができます。
「Amazon Elastic Compute Cloud (Amazon EC2)」は、AWS クラウドでスケーラブルなコンピューティング容量を提供します。必要な数の仮想サーバーを起動することができ、迅速にスケールアップまたはスケールダウンができます。
「AWS Identity and Access Management (IAM)」は、AWS リソースへのアクセスを安全に管理し、誰が認証され、使用する権限があるかを制御するのに役立ちます。
「AWS Systems Manager」は、AWS クラウドで実行されるアプリケーションとインフラストラクチャの管理に役立ちます。アプリケーションとリソースの管理が簡略化され、オペレーション上の問題の検出と解決時間が短縮され、AWS リソースを大規模かつセキュアに管理できるようになります。このパターンは、Systems Manager の機能の一つである「Session Manger」を使用します。
Amazon Virtual Private Cloud (Amazon VPC) を使用すると、定義した仮想ネットワーク内で AWS リソースを起動できます。この仮想ネットワークは、お客様自身のデータセンターで運用されていた従来のネットワークに似ていますが、AWS のスケーラブルなインフラストラクチャを使用できるというメリットがあります。
その他のツール
「HashiCorp Terraform
」は、コードでクラウドインフラストラクチャとリソースをプロビジョニングおよび管理するのに役立つオープンソースのコードとしての Infrastructure as Code (IaC) ツールです。このパターンは「Terraform CLI 」を使用しています。
コードリポジトリ
このパターンのコードは、GitHub·内の「Session Manager と Amazon EC2 Instance Connectを使用して踏み台ホストにアクセスする
ベストプラクティス
コードのセキュリティと品質を向上させるために、自動コードスキャンツールの使用をお勧めします。このパターンは、IaC 用の静的コード分析ツールである「Checkov
」を使用してスキャンされました。最低でも、 terraform validateとterraform fmt -check -recursiveTerraform コマンドを使用して基本的な検証とフォーマットのチェックを行うことをお勧めします。IaC の自動テストを追加することは良い習慣です。Terraform コードをテストするさまざまな方法の詳細については、「HashiCorp Terraform のテスト
」(Terraform ブログ記事) を参照してください。 デプロイ中、新しいバージョンの「Amazon Linux 2 AMI
」が検出されるたびに、Terraformは置換 EC2 インスタンスを使用します。これにより、パッチやアップグレードを含む新しいバージョンのオペレーティングシステムがデプロイされます。デプロイスケジュールの頻度が低い場合、インスタンスに最新のパッチが適用されないため、セキュリティ上のリスクが生じる可能性があります。デプロイされた EC2 インスタンスには、セキュリティパッチを頻繁に更新して適用することが重要です。詳細については、「Amazon EC2 での更新管理」を参照してください。 このパターンは概念実証であるため、
AmazonSSMManagedInstanceCoreなどの AWS マネージドポリシーを使用します。AWS マネージドポリシーは、一般的なユースケースを対象としていますが、最小特権のアクセス権限は付与しません。ユースケースに応じて、このアーキテクチャにデプロイされたリソースに最小特権のアクセス権限を付与するカスタムポリシーを作成することをお勧めします。詳細については、「AWS マネージドポリシーの使用を開始し、最小特権のアクセス許可に移行する」を参照してください。SSH キーへのアクセスを保護し、キーを安全な場所に保存するにはパスワードを使用してください。
踏み台ホストのロギングとモニタリングを設定します。記録とモニタリングは、運用面とセキュリティ面の両方の観点から、システムを保守する上で重要な部分です。踏み台ホストの接続とアクティビティをモニタリングする方法は複数あります。詳細については、Systems Manager ドキュメントの次のトピックを参照してください。
エピック
| タスク | 説明 | 必要なスキル |
|---|---|---|
コードリポジトリを複製します。 |
| DevOps エンジニア、開発者 |
ディレクトリから Terraform を開始します。 | このステップは最初のデプロイにのみ必要です。このパターンをレデプロイする場合、次の手順に進んでください。 クローンしたリポジトリのルートディレクトリに、以下のコマンドを入力します。
注記または、config.tf ファイルを開き、 | DevOps エンジニア、開発者、Terraform |
リソースのデプロイ |
| DevOps エンジニア、開発者、Terraform |
| タスク | 説明 | 必要なスキル |
|---|---|---|
SSH 接続を設定します。 | SSH 設定を更新して、Session Manager を介して SSH 接続を有効にします。手順については、「Session Manager の SSH 接続を許可」を参照してください。これにより、許可されたユーザーは、プロキシコマンドを入力し、Session Manager セッションを開始し、双方向接続を介してすべてのデータを転送することができます。 | DevOps エンジニア |
SSH キーを生成します。 | 次のコマンドを入力して、ローカルで非公開と公開 SSH キーペアを生成します。このキーペアで踏み台ホストに接続します。 | DevOps エンジニア、開発者 |
| タスク | 説明 | 必要なスキル |
|---|---|---|
インスタンスの ID を取得します。 |
| AWS 全般 |
SSH パブリックキーを送信します。 | 注記このセクションでは、踏み台ホストのインスタンスメタデータにパブリックキーをアップロードします。キーがアップロードされたら、60 秒以内に踏み台ホストとの接続を開始してください。60 秒後、パブリックキーは削除されます。詳細については、このパターンの「トラブルシューティング」セクションを参照してください。踏み台ホストに接続する前にキーが削除されないように、次の手順をすぐに実行してください。
| AWS 全般 |
踏み台ホストに接続します。 |
注記踏み台ホストとの SSH 接続を開く方法は他にもあります。詳細については、このパターンの「追加情報」セクションの「踏み台ホストとの SSH 接続を確立するための代替方法」を参照してください。 | AWS 全般 |
| タスク | 説明 | 必要なスキル |
|---|---|---|
デプロイされたリソースを削除します。 |
| DevOps エンジニア、開発者、Terraform |
トラブルシューティング
| 問題 | ソリューション |
|---|---|
踏み台ホストに接続しようと試みる時の |
|
踏み台ホストに接続しようと試みる時の | パブリックキーが踏み台ホストにアップロードされたら、60 秒以内に接続を開始してください。60 秒が経過すると、そのキーは自動的に削除され、そのキーを使用してインスタンスに接続できなくなります。その場合は、手順を繰り返してそのキーをインスタンスに再送信できます。 |
関連リソース
AWS ドキュメント
「AWS Systems Manager Session Manager」(Systems Manager のドキュメント)
「AWS CLI 用の Session Manager プラグインをインストールする」(Systems Manager のドキュメント)
「Session Manager の SSH 接続を許可」(Systems Manager のドキュメント)
「EC2 Instance Connect の使用について」(Amazon EC2 のドキュメント)
「EC2 Instance Connect で接続」(Amazon EC2 のドキュメント)
「Amazon EC2 の Identity and Access Management」(Amazon EC2 のドキュメント)
「IAM ロールを使用して、Amazon EC2 インスタンスで実行されているアプリケーションにアクセス許可を付与する」(IAM ドキュメント)
IAM におけるセキュリティのベストプラクティス」(IAM のドキュメント)
「セキュリティグループを使用してリソースへのトラフィックを制御する」(Amazon VPC ドキュメント)
その他のリソース
「コマンド：検証
」(Terraform のドキュメント) 「コマンド：fmt
」(Terraform のドキュメント) 「HashiCorp Terraform のテスト
」(HashiCorp ブログ記事）
追加情報
踏み台ホストとの SSH 接続を確立するための代替方法
ポート転送
この -D 8888 オプションを使用して、動的ポートフォワーディングで SSH 接続を開くことができます。詳細については、「explainshell.com」で「以下の手順
ssh -i $PRIVATE_KEY_FILE -D 8888 ec2-user@$INSTANCE_IDこの接続は、ローカルブラウザからのトラフィックを踏み台ホスト経由で転送できる SOCKS プロキシを開くようなものです。Linux または MacOS をご使用の場合、すべてのオプションを表示するには、man ssh を入力します。SSH リファレンスマニュアルが表示されます。
提供されたスクリプトを使用
「エピック」セクションで、Session Manager で踏み台ホストに接続に説明されている手順を手動で実行する代わりに、コードリポジトリに含まれている connect.sh スクリプトを使用することができます。このスクリプトは SSH キーペアを生成し、パブリックキーを EC2 インスタンスにプッシュして、踏み台ホストとの接続を開始します。コマンドを実行すると、タグとキー名を引数として渡します。以下はスクリプトを実行するコマンドの例です。
./connect.sh sandbox-dev-bastion-host my_key
