Day1～AWSで最初に行うべき設定　セキュリティ編 Part2

はじめに

こんにちは

前回、「Day1にAWSアカウントに最初に行うべき設定」のセキュリティカテゴリの設定2件についてご紹介しました。（まだの方はこちらから是非読んでみてください。）

Day1～AWSで最初に行うべき設定　セキュリティ編 Part1

この記事は残る3件のセキュリティ設定について紹介します。

※この記事はあくまでもAWSから公開されている「Day 1 with Amazon Web Services　AWSご利用開始時に最低限おさえておきたい10のこと」を実現する方法の一例を紹介しています。この設定をしていれば必ず安全であると保証するものではありません。

(3)認証情報を埋め込まない

AWS上のリソースを操作する場合は、必要な権限を持った認証情報を使用します。

例えば、EC2上のソフトウェアからRDSのデータを取得しようとするときは、ソフトウェアに認証情報を持たせる必要があります。IAMユーザを作成すれば、そのユーザがもつ権限の認証情報を使うことができますが、IAMユーザの認証情報は静的であり、EC2サーバに埋め込むとセキュリティを維持するためキーのローテーション等の検討が必要になります。EC2サーバに権限をもたせる際は、動的に認証情報がローテーションされるIAMロールを使用することが推奨されています。

ここでは「EC2に（は）IAMロールを使用」し、EC2サーバからAmazon S3上のファイルにアクセスする手順を説明します。予め、EC2サーバとS3バケットを作成してください。バケットにはファイルを格納してください。

まず、EC2からAWS上のリソースを操作するためのモジュールをインストールします。EC2サーバにSSHで接続し、root権限のあるユーザーで以下のコマンドを実行します。

OSがAmazon Linuxのサーバにはデフォルトでインストールされていますが、コマンドを実行し、モジュールを最新の状態にすることをお勧めします。インストール後に次のコマンドを実行してインストールできているか確認しましょう。バージョン情報が表示されればインストール完了です。

それでは、S3上のファイルにアクセスしてみます。

認証情報を設定していないためエラーになってしまいました。

ここで静的な認証情報を設定することも可能ですが、先述の通り、セキュリティを維持するためIAMロールで動的な認証情報を設定します。

AWSマネジメントコンソールにログインし、EC2を押下します。

EC2のダッシュボードで左カラムのインスタンスを押下します。

権限を付与したいインスタンスにチェックを入れ、「アクション」＞「インスタンスの設定」＞「IAMロールの割り当て/置換」の順に押下します。

「新しいIAMロールを作成する」を押下します。

「ロールの作成」を押下します。

ロールの作成画面が開いたら、権限を使用するサービスを選択します。
今回はEC2に使用するため「AWSサービス」＞「EC2」を選択し、「次のステップ：アクセス権限」を押下します。

どのような権限を付与するか選択します。今回は「AmazonS3ReadOnlyAccess」の権限を付与します。
「AmazonS3ReadOnlyAccess」にチェックを入れます。
テキストボックスに「s3」など入力すると探しやすいです。チェックを入れたら「次のステップ：確認」を押下します。

任意のロール名を入力し、「ロールの作成」を押下します。

 

ロールを作成したらロールの割り当て画面に戻ります。矢印を押下し、IAMロールのリストを再読み込みします。

プルダウンメニューを開き、先ほど作ったIAMロール名を選択します。選択後は「適用」を押下します。

「閉じる」を押下して戻ります。

では、権限が付与されたか実際に確認してみましょう。EC2にSSHでログインし、先ほどと同じコマンドを実行します。

S3バケットの一覧が表示されました。

バケットの中も確認してみましょう。

バケット内のファイルの一覧も表示できました。

(4)証跡の取得

AWS CloudTrailはAWSアカウント内で発生した様々な操作のログを取得できるサービスです。マネジメントコンソール上の操作だけでなく、APIの呼び出し履歴等も取得できます。この機能は、セキュリティインシデントが発生した場合に、どのような操作が行われたかを検証するために重要になります。また、監視のサービスであるCloudWatchと連携することで、特定の操作が行われた際に通知を行うこともできます。

この項目では、「AWS CloudTrailによる操作ログの取得を設定する」手順を説明します。

まずAWSマネジメントコンソールにサインインし、CloudTrailを押下します。
CloudTrailのダッシュボードが開いたら、「証跡の作成」を押下します。
証跡情報の作成画面では、任意の証跡名を入力し、証跡情報を全てのリージョンに適用の項目は「はい」にチェックを入れます。

ログを保存するS3バケットを指定します。この例では新しくバケットを作成しましたが、既存のバケットを指定することもできます。
S3バケット名を入力したら「作成」を押下します。

ログが出力されるようになりました。試しに、EC2サーバを停止してみて、そのログを確認します。

ログが出力されているか確認しましょう。（ログが出力されるまで10分ほどかかります）
AWSマネジメントコンソールからS3の画面を開き、証跡情報の生成の際指定したバケットを開きます。

「AWSLogs」＞アカウントID＞「CloudTrail」＞リージョン名＞年＞月＞日に遷移し、保存されているログを開くと、json形式で出力されたログを確認することが出来ます。

しかしこれでは、インスタンスを停止させたログがどの部分か分かりづらいです。

ログを検索できるようにしましょう。CloudTrailのダッシュボードで「証跡情報」を押下し、先ほど作った証跡情報の名前を押下します。

CloudWatch Logsの項目で「設定」を押下します。

新規または既存のロググループに任意のロググループ名を入力し、「次へ」を押下します。

CloudWatch Logsの権限を設定する画面に遷移するので、設定を変えず「許可」を押下します。

エラーが表示されてしまった場合は、CloudWatch Logsの項目で再度「次へ」を押下します。

ポリシー名で先ほど作成されたポリシーを指定して、「許可」を押下します。

CloudWatch Logsの設定が完了しました。

実際にログを見てみましょう。

AWSマネジメントコンソールから「CloudWatch」を押下し、ダッシュボードの左カラムから「ログ」を押下します。

先ほど作成したロググループが表示されたらロググループ名を押下します。

時系列で沢山のログが表示されると思います。上部の検索窓に「stop」と入力し、表示されたログを開きます。

eventNameがStopInstancesのログが見つかりました。これで、インスタンスが停止された時間を知ることができるようになりました。

しかし、例えば意図しないインスタンスの停止などは、後からログを検索するのではなく、起きた時点で知りたいものです。CloudWatch Logsでは指定したログを検出すると自動で通知する仕組みを簡単に作ることが出来ます。EC2サーバが停止したらメール通知が来るように設定してみましょう。

先ほどのロググループを選択する画面を開き、「メトリクスフィルタの作成」を押下します。

フィルタパターンに「StopInstances」と入力し「メトリクスの割り当て」を押下します。

任意のメトリクス名前空間とメトリクス名を入力し、「フィルタの作成」を押下します。

フィルタが作成されたら、「アラームの作成」を押下します。

名前と説明に任意の値を入力します。

今回はEC2_StopというメトリクスでStopInstancesが1回以上出力された際に通知したいので、次の時：EC2_Stopが>=1となるように設定します。

欠損データの処理方法で「無視（アラーム状態を維持する）」を選択し、アクションの「新しいリスト」を押下します。

ここでは通知先の一覧を作成することができます。通知の送信先に任意のリスト名を入力し、メールリストには通知したいメールアドレスを入力します。（複数の宛先を指定することも可能です）

新しいメールアドレスの確認画面が表示されたら、指定したメールアドレス宛に確認メールが来ているはずです。

確認メール内の「Confirm subscription」のリンクを押下します。

正常に確認出来たら次のような画面が表示されます。この画面はこのまま閉じてしまってかまいません。

実際に通知が来るか試してみましょう。EC2サーバを停止してみます。

数分後、メールが送信されました。このように、ログは出力してためるだけでなく、ログの出力内容によって自動的にアクションを起こすことができるため活用しましょう。

(5)各レイヤでのセキュリティ対策

AWSでは様々なセキュリティ対策の手段やサービスが提供されています。ユーザ自身で、効果と効率を考慮し、最適な設定を選択する必要があります。ここでは「アクセス設定を必要最低限に設定」するうえで使用頻度の高い、セキュリティグループの設定手順について説明します。

まず、EC2サーバにどのセキュリティグループが適用されているか確認します。EC2のダッシュボードで対象のサーバにチェックを入れ、詳細のセキュリティグループの項目に設定されているセキュリティグループ名を確認します。

EC2のダッシュボードで左カラムの「セキュリティグループ」を押下します。

EC2サーバに適用されていたセキュリティグループにチェックを入れ、「インバウンド」＞「編集」を押下します。

既に設定されているルールを削除します。

「保存」を押下します。

EC2サーバに接続してみると、接続できないことが確認できるはずです。このようにEC2サーバは明示的に許可をしていない場合はアクセスができません。

次に、特定のネットワークからのみ接続できるルールを設定してみます。

再度セキュリティグループのインバウンドで「修正」を押下します。

インバウンドのルールの編集では、下の図のように設定します。このとき、ソースにはEC2サーバに接続する端末のグローバルIPアドレスを設定します。ソースはどこからの接続を許可するかという設定になります。

設定を保存したらEC2サーバに接続してみます。問題なく接続できることが確認できるはずです。（接続できないときはグローバルIPアドレスやプロトコルが間違っていないか再度確認しましょう）

 

次に、セキュリティグループの設定を変えずに、ソースに設定した以外のネットワークからEC2サーバに接続してみてください。接続できないことが確認できます。

セキュリティグループを活用して、限られたネットワークやプロトコルからの接続のみを許可することでセキュリティを高めることができます。なお、セキュリティグループの設定変更はサーバ起動中でも行うことができ、再起動等する必要なく即時反映されます。

おわりに

今回はセキュリティに関する3つの設定を行いました。

これにより、

・EC2サーバに動的な認証情報を持たせること

・AWS CloudTrailによって操作ログを取得すること

・アクセス設定を必要最低限に設定するためにセキュリティグループを設定すること

がそれぞれ実現できました。

次回の記事では、コスト最適化するための設定方法を紹介します。