SOA-#041

複数の IP アドレス

EC2 インスタンスに複数の Elastic Network Interface(ネットワークインターフェース または ENI)を接続することができ、それぞれのネットワーク IP は別々の SSL 証明書を使用してコンポーネントを実行させることができます。

※複数の IP アドレス インスタンスに複数のプライベート IPv4 および IPv6 アドレスを指定できます。インスタンスに指定できるネットワークインターフェイスとプライベート IPv4 および IPv6 アドレスの数は、インスタンスタイプによって異なります。

次のような場合、複数の IP アドレスを VPC 内のインスタンスに割り当てると便利です。

・1 つのサーバーで複数の SSL 証明書を使用し、各インターフェイスに各 IP アドレスに割り当てることで、1 つのサーバーで複数のウェブサイトをホストする。

・各ネットワークインターフェイス用に複数の IP アドレスを持つネットワークアプライアンス (ファイアウォールやロードバランサーなど) を運用する。

・インスタンスでエラーが発生した場合に、セカンダリ IP アドレスをスタンバイインスタンスに再割り当てすることによって、内部トラフィックをスタンバイインスタンスにリダイレクトする。
参考URL:複数の IP アドレス

IAM SAML ID プロバイダーの作成

SAMLフェデレーションを Active Directory と AWS の間に ID プロバイダーを使用してアクセス許可を管理し、各ユーザーに一時的な認証情報を付与することができます。
参考URL:IAM SAML ID プロバイダーの作成

※SAML 2.0 ベースのフェデレーションについて
SAMLフェデレーションは Active Directory と AWS 間の ID ブローカーとして使用できます。
AWS は SAML 2.0 (Security Assertion Markup Language) を使用した ID フェデレーションをサポートします。これは、多くの ID プロバイダー (IdP) により使用されているオープンスタンダードです。この機能はフェデレーティッドシングルサインオン (SSO) を有効にします。したがって、組織内の全員について IAM ユーザーを作成しなくても、ユーザーは AWS マネジメントコンソール にログインしたり、AWS API オペレーションを呼び出したりできるようになります。SAML を利用すると、カスタム ID プロキシコードを記述する代わりに IdP のサービスを利用できるため、AWS で簡単にフェデレーションを設定できます。
参考URL：SAML 2.0 ベースのフェデレーションについて

Classic Load Balancer メトリクス

SurgeQueueLength は正常なインスタンスへのルーティングを保留中のリクエスト (HTTP リスナー) または接続 (TCP リスナー) の合計数です。キューがいっぱいになると拒否されて、SpilloverCount がカウントされます。したがって、SurgeQueueLength を監視することで目的を達成できます。

※Classic Load Balancer メトリクス
・SurgeQueueLength
正常なインスタンスへのルーティングを保留中のリクエスト (HTTP リスナー) または接続 (TCP リスナー) の合計数。キューの最大サイズは 1,024 です。追加のリクエストまたは接続は、キューがいっぱいになると拒否されます。詳細については、「SpilloverCount」を参照してください。

・SpilloverCount
サージキューがいっぱいなため、拒否されたリクエストの総数。
[HTTP リスナー] ロードバランサーは、HTTP 503 エラーコードを返します。
参考URL:Classic Load Balancer メトリクス

フォールトトレランス

3 つのアベイラビリティーゾーンにそれぞれ 2 台のインスタンスをデプロイすることで、アベイラビリティーゾーンがダウンした場合でも、4 台のインスタンスが実行された状態でフォールトトレランスが提供されます。これは、6 台のインスタンスを稼働させることで、費用対効果の高いソリューションとなります。

■以下は間違いです。
・3 つのアベイラビリティーゾーンにそれぞれ 1 台のインスタンスをデプロイします。
→4 台のインスタンスの基準を満たしていないため間違いです。

・2 つのアベイラビリティーゾーンにそれぞれ 4 台のインスタンスをデプロイします。
→8 台のインスタンスを実行するコスト効率の良いソリューションではないため間違いです。

・2 つのアベイラビリティーゾーンにそれぞれ 2 台のインスタンスをデプロイします。
→1 つのアベイラビリティーゾーンが失われた場合に、2 台のインスタンスしか残らないため、フォールトトレランスを提供しないため間違いです。

AWS Systems Manager Patch Manager

AWS Systems Manager Patch Manager は、セキュリティ関連の更新パッチをマネージドインスタンスに適用するプロセスを自動化します。Linux ベースのインスタンスの場合は、セキュリティに関連しない更新プログラムのパッチもインストールできます。オペレーティングシステムのタイプ別に、Amazon EC2 インスタンスまたはオンプレミスサーバー、および仮想マシン (VM) にパッチを適用できます。Windows Server、Ubuntu Server、Red Hat Enterprise Linux (RHEL)、SUSE Linux Enterprise Server (SLES)、CentOS、Amazon Linux、Amazon Linux 2 のサポートされているバージョンが対象になります。インスタンスをスキャンし、見つからないパッチのレポートのみを表示できます。または、すべての見つからないパッチをスキャンして自動的にインストールできます。
参考URL:AWS Systems Manager Patch Manager

※Amazon EC2 フリート
Amazon EC2 フリートは、さまざまな Amazon EC2 インスタンスタイプ、アベイラビリティーゾーン、オンデマンド、Amazon EC2 リザーブドインスタンス (RI)、Amazon EC2 スポット購入モデルの間での Amazon EC2 キャパシティーのプロビジョニングを簡素化する新機能です。単一の API コールで、EC2 インスタンスタイプや購入モデルの間でキャパシティーをプロビジョンして、必要な規模、パフォーマンス、コストを達成できます。

■以下は間違いです。
・インスタンス全体にセキュリティパッチが適用されるように、AWS サポートにリクエストします。
→システム管理者の責任において EC2 インスタンスにパッチを適用するので効率的ではありません。

・毎週のメンテナンスウィンドウで AWS にセキュリティパッチを自動的に適用します。
→ AWS は EC2 インスタンスに自動的にパッチを適用しないため間違いです。

・EC2 インスタンスの停止と開始を行い、強制的にセキュリティパッチを適用します。
→EC2 インスタンスを再起動したのみでは、強制的にセキュリティパッチを適用できないため間違いです。

AWS Shield アドバンスド

AWS Shield アドバンスドが 24 時間 365 日の DDoS 対応で DDoS 保護を提供し、スパイクに対する支援とコスト面での保護を提供します。

※AWS Shield アドバンスド
Amazon Elastic Compute Cloud、Elastic Load Balancing (ELB)、Amazon CloudFront、Amazon Route 53、AWS Global Accelerator などのリソースで実行されるウェブアプリケーションを標的とした攻撃に対する高レベルな保護には、AWS Shield アドバンスド をサブスクライブできます。AWS Shield アドバンスド は、DDoS 攻撃に対するこのようなリソースの拡張保護を提供します。
この追加された保護の例として､Shield アドバンスド を使用して Elastic IP アドレスを保護する場合、攻撃中に Shield アドバンスド は AWS ネットワークの境界にネットワーク ACL を自動的にデプロイします。これにより、Shield アドバンスド はより大きな DDoS イベントに対して保護を提供します。通常、ネットワーク ACL は Amazon VPC 内の Amazon EC2 インスタンスの近くで適用されます。ネットワーク ACL は、Amazon VPC とインスタンスが処理できるだけの大きさの攻撃を緩和できます。たとえば、Amazon EC2 インスタンスに接続されたネットワークインターフェイスが最大 10 Gbps を処理できる場合、10 Gbps を超えるボリュームは遅くなり、そのインスタンスへのトラフィックをブロックする可能性があります。攻撃中に、Shield アドバンスド はネットワーク ACL を AWS 境界に昇格させ、数テラバイトのトラフィックを処理できます。ネットワーク ACL は、典型的なネットワークの容量を超えてリソースを十分に保護することができます。
AWS Shield アドバンスド のお客様は、DDoS 攻撃を受けている中、24 時間 365 日体制の DDoS response team (DRT) にサポートを依頼できます。また、高度なリアルタイムのメトリクスとレポートへの排他的アクセスが可能であり、AWS リソースに対する攻撃の広範な可視性を得られます。DRT のサポートにより､AWS Shield アドバンスド には、ネットワークレイヤー (レイヤー 3) およびトランスポートレイヤー (レイヤー 4) 攻撃だけでなく、アプリケーションレイヤー (レイヤー 7) 攻撃に対しても、DDoS 攻撃のインテリジェント検出および軽減が含まれます。
参考URL:AWS Shield アドバンスド

■以下は間違いです。
・Amazon Inspector
→Amazon Inspector は自動化されたセキュリティを評価して、AWS にデプロイしたアプリケーションのセキュリティとコンプライアンスを向上させるサービスのため間違いです。

・AWS WAF
→AWS WAF は ファイアウォールであり、24 時間 365 日のサポートは提供しないため間違いです。

・AWS Systems Manager
→AWS Systems Manager は、AWS でご利用のインフラストラクチャを可視化し、制御するためのサービスのため間違いです。

AWS Config

AWS Config では、パブリックアクセスのある S3 バケットが作成された場合に監視とアラートを行うころができます。

※インターネットからアクセス可能な S3 バケットを調べる方法
S3 バケットへのパブリックアクセスが可能かどうかは、Amazon S3 コンソールのバケットのアクセス許可チェックを使うか、AWS Trusted Advisor の Amazon S3 バケットアクセス許可チェックを使って調べることができます。AWS アカウントに多くの S3 バケットがある場合は、AWS Config を使用して、どのバケットが読み取りまたは書き込みのパブリックアクセスを許可されているのかを迅速に特定することができます。さらに、最初に確認した後で S3 バケットのパブリックアクセスが可能となった場合、それを通知するように AWS Config を設定することもできます。

◇動画：Ioannis が、AWS Config を使用して S3 バケットを保護する方法について説明します。

参考URL:インターネットからアクセス可能な S3 バケットを調べる方法を教えてください。

■以下は間違いです。
・バケットのバージョニングを有効にします。
→バージョニングが有効なバケットでは、オブジェクトを誤って削除または上書きしても復元するため用途が異なります。

・バケットポリシーを使用して、PutObject の Action に対して DENY ステートメントを設定します。
・IAM ポリシーを使用し、PutObject の Action に対して DENY ステートメントを設定します。
→内部ユーザに対しても制限がかかるため間違いです。