セキュリティは AWS の重要な柱であり、HPC データは、多くの場合ミッションクリティカルな資産です。先ほど作成したラボ環境はお使いのアカウントで動作しており、これはお客様がデータとアプリケーションの完全な制御と所有権を持っていることを意味します。このモジュールでは、AWS のセキュリティに対するアプローチと、HPC アプリケーションとデータをセキュアに保つために使用できるいくつかの主要テクノロジーについて検討します。
対象トピック:
- AWS 共有責任モデル
- AWS Identity and Access Management (IAM) の使用
- ネットワークセキュリティ
- 認証
クラウド内の HPC インフラストラクチャのセキュリティを評価する時は、以下の 2 つを理解し、区別することが重要です。
- クラウドサービスプロバイダー (AWS) が実装して運用するセキュリティ対策 –「クラウドのセキュリティ」
- AWS のサービスを利用するお客様のコンテンツとアプリケーションのセキュリティが関連する、お客様が実装して運用するセキュリティ対策 –「クラウド内のセキュリティ」
AWS はクラウドのセキュリティを管理する一方、クラウド内のセキュリティはお客様の責任です。お客様は、オンサイトデータセンター内のアプリケーションと全く同様に、それぞれのコンテンツ、プラットフォーム、アプリケーション、システム、およびネットワークを保護するためにどのようなセキュリティを選択して実装するかに対する主導権を持っています。
お客様の AWS アカウント内でデプロイされたソリューションであることから、ラボのセキュリティがお客様の責任の一環であるとご理解いただくことが重要です。詳細については、4 時間の無料オンライントレーニングにご参加いただくか、AWS セキュリティホワイトペーパーをお読みください。
より優れたセキュリティと秩序のため、AWS アカウントへのアクセス権 (カスタムパーミッションと共に作成する ID) を特定のユーザーに付与することができます。前のモジュールで起動した HPC 環境では、アカウント内の AWS のサービスとリソースの全てに完全にアクセスできるシングルサインイン ID である AWS ルートユーザーを使用しました。実稼働ワークロードのためには、CloudFormation テンプレートをデプロイするために十分なパーミッションを持つ別のユーザー (IAM ユーザーとして知られています) を作成して使用することがベストプラクティスです。
ラボの全体が新しく作成された Virtual Private Cloud (VPC) に含まれており、これは同じアカウントで実行されている他の環境とアプリケーションからの分離を実現します。この VPC 内では、複数のサブネットが VM およびロードバランサーを含むホスト EC2 サービス用に使用されています。
ラボのテンプレートでパラメータとして指定された CIDR 範囲は、セキュリティグループおよびその他 VPC コンポーネントを使用して HTTPS アクセスを Application Load Balancer に、SSH アクセスをクラスターのヘッドノードに制限するために使用されています。HTTPS と SSH 証明書が異なること、および HTTPS 証明書は自己署名であるために実稼働での使用には推奨されないことに注意してください。
セキュリティグループは、ソース CIDR、プロトコル、およびポートに基づいてインスタンスへのトラフィックを許可し、妨げる仮想ファイアウォールとして機能します。1 つまたは複数のセキュリティグループがインスタンスに関連付けられています。セキュリティグループにはルールが追加され、関連付けられたインスタンスへのトラフィック、またはそこからのトラフィックを許可します。セキュリティグループのルールはいつでも変更可能です。新しいルールは、そのセキュリティグループに関連付けられているインスタンスすべてに自動的に適用されます。
以下のスクリーンショットに示されるように、インスタンスに関連付けられているセキュリティグループは、インスタンスの説明と共に EC2 コンソールから表示できます。詳細については、Amazon EC2 セキュリティグループのユーザーガイドを参照してください。
上記のスクリーンショットには Amazon EC2 コンソールが表示されており、セキュリティグループを強調しています。ボックス 1 は選択された Amazon EC2 インスタンスのセキュリティグループ、ボックス 2 は EC2 コンソールを通じてセキュリティグループにアクセスするための代替的な方法が強調されています。
AWS Identity and Access Management (IAM) 内で管理されているユーザーはネイティブな AWS のサービスにしか使用できないため、ラボでは AWS Directory Service 内のシンプルな製品である Simple AD を介してユーザー認証を実装します。この製品は、Microsoft Active Directory との互換性を提供します。
この認証ソリューションは、クラスターのヘッドノードで実行される EnginFrame ウェブアクセスでユーザー認証情報を検証することと、クラスターノード内のユーザーが動的に作成および削除されるたびにユーザーを反映することの両方に使用され、EFS での一貫性のあるファイルアクセスを確保するために均一な名前空間を提供します。
HPC インフラストラクチャを設計して構築するにあたり、Windows 互換性を向上させ、AWS でホストされるディレクトリとオンプレミスのディレクトリの間に信頼関係を築くために、Microsoft AD Directory Service 製品への切り替えを検討してもよいでしょう。
Amazon EC2 は EC2 インスタンスへの特権アクセスにパブリックキー認証を使用します。パブリックキー認証はパスワード認証よりも安全であり、ターミナル受信者がプライベートキーを使用してデータを複合化する間、転送されたデータの暗号化にパブリックキーを使用します。パブリックキーとプライベートキーは、キーペアと呼ばれます。
マスターインスタンスとコンピューティングインスタンスに関連付けられたキーペアが、ラボの起動時にパラメータとして入力されます。これは、Sudo パーミッションがあり、パスワードがない ec2-user アカウントとしてマスターインスタンスとコンピューティングインスタンスの両方にログオンするときに必要です。
以下にあるように、パブリック IP アドレスと SSH キーを使用してお使いのインスタンスにログオンします。
ssh-i$YOUR_KEY_PAIR_FILE MASTER_ELASTIC_IP ec2-user@$