どうも、Tです。
AWSアカウントを作成しましたが、使い始める前にセキュリティを高めておきたいものです。
なんせインターネット経由で様々なことができるうえに、クレジットカード登録もしているため、何かあったときには、すべて自分に跳ね返ってきます。
ということで、AWSアカウント取得後に設定しておいた方が良い部分をまとめました。
目次
アカウント関連
ルートアカウントのMFA（Multi-Factor Authentication）の設定
最初に取得したAWSアカウントは、ルートアカウントと呼ばれAWSのすべてのに関する権限を持っていきます。
アカウント・パスワードだけで入力できるのは、心細いのでスマホなどを使った2要素認証を設定しておきます。
今回は、自分のiPhoneアプリで利用できるようにしました。
画面右上にあるアカウントをクリックし「セキュリティ認証情報」をクリックします。
「セキュリティ認証情報に進む」をクリックします。
「Multi-Factor Authentication(MFA)」をクリックします。
「MFAの有効化」をクリックします。
「仮想MFAデバイス」を選択して、「次のステップ」をクリックします。
仮想MFAデバイスは、スマホのアプリケーションを使う場合などです。
ハードウェアMFAは、MFA専用の機器を使う場合に選択するのですが、個人用途や要件がないようであれば仮想MFAで十分かと考えています。
「次のステップ」をクリックします。
QRコードが表示されます。
MFAに利用できるアプリケーションでQRコードを読み込ませます。
僕は、iPhoneアプリのAuthyを利用しています。
Google Authenticatorも利用できますが、下記のような記事もあるので各自判断で利用しましょう。
登録が完了するとアプリで下記のようにコードが表示されます。
※AWSのアイコンは手動で変更しています。
認証コードを入力して「仮想MFAの有効化」をクリックします。
2つありますが、認証コード1は、現在アプリに表示されているコード。
認証コード2は、認証コード1のあとにアプリに表示されたコートです。
デバイスの関連付けが行われたことを確認し、「完了」をクリックします。
関連付けされたシリアルが表示されます。念のため確認しておきましょう。
サインアウトします。
ログインします。
ログイン時にMFAコードの入力項目が表示されます。
コードを入力してログインできれば設定完了です。
IAMアカウント（個人ユーザーアカウント）の作成
ルートアカウントは、全権限をもった重要なユーザーのため、普段使いするIAMアカウントを作成します。
基本的には、複数人で行う運用で発揮する機能ですが、ルートアカウントを常時利用するのは好ましくないので、個人利用の人も設定しておきましょう。
アカウントエイリアスの作成
IAMユーザーとルートユーザーは、ログインするURLが異なります。
IAMユーザー用のログインURLを設定します。
メニューから「IAM」をクリックします。
IAMユーザーのサインインリンクが表示されいます。
ここは、ランダムな数字の列になっているのでわかりやすいURLを付けます。
「カスタマイズ」をクリックします。
「アカウントエイリアス」にわかりやすい名前（組織名・会社名など）を入力し「はい、作成する」をクリックします。
URLが変わったことを確認します。
グループの作成
IAMアカウントは、グループに所属して権限を制限できます。
まずはグループを作成します。
「グループメニュー」から「新しいグループの作成」をクリックします。
「グループ名」を入力し、「次のステップ」をクリックします。
ポリシーのアタッチで、管理者権限に必要な「AdministratorAccess」をチェックします。
※必要な権限により選択するものはわかります。
グループ名とポリシーを確認し「グループの作成」をクリックします。
グループができました。
ユーザーの作成
次にユーザーを作成します。
「ユーザー」メニューから「ユーザーを追加」をクリックします。
「ユーザー名」「アクセスの種類」「コンソールのパスワード」「パスワードのリセットが必要」のうち必要なものを設定し、「次のステップ」をクリックします。
僕は、以下のような設定にしました。
先ほど作ったグループにユーザーを追加します。
グループにチェックを入れ、「次のステップ」をクリックします。
設定内容を確認し、「次のステップ」をクリックします。
ユーザーの追加が完了しました。
ユーザーをダブルクリックします。
認証情報タブの「MFAデバイスの割り当て」がデフォルトで「いいえ」になっているで、
ルートアカウントと同じ手順でこちらもMFA対応にしておきましょう。
IAMアカウントでログインするときは、ルートアカウントと少し手順が異なります。
下記の画面にて、上記で設定した「アカウントエイリアス」に設定した値を入力します。
ユーザー名とパスワードにIAMアカウント作成時の情報を入力してサインインできれば完了です。
パスワードポリシーの設定
アカウントのパスワードは、最初かなり緩めに設定されています。
MFAを設定してればある程度安心できますが、パスワードポリシーを少し厳しめに設定しました。
以下は、僕が設定した値です。
設定後、「パスワードポリシーの適用」をクリックします。
パスワードポリシーが反映されました。
セキュリティステータスの確認
IAMのダッシュボード画面の「セキュリティステータス」を確認しておきます。
ここまでの手順を行っていれば、すべてグリーンのチェックボックスになっているはずです。
オレンジ色の警告になっている場合は、設定内容を確認しましょう。
通知関連
AWS関連の通知は、デフォルトでほぼ何も届かないので、自分で設定しておきましょう。
従量課金のため、金額などについては取り返しがつかない状態にならないようにしたいです。
請求書のメール通知設定
AWSはデフォルトで請求書を送ってきません。
マネジメントコンソールから取得することはできますが、メールでためていく方が簡単なので、メールでPDFファイルを送付してくれるように設定します。
右上のアカウントをクリックして「請求ダッシュボード」をクリックします。
メニューから「設定」をクリックします。
「請求設定」で「電子メールでPDF版請求書を受け取る」にチャックを入れて設定を有効化します。
ちなみに、請求書の中にアカウント情報などは記載されないため情報漏洩する心配はありません。
PDF 版の請求書には、支払い方法 (名前、住所など) に関連する情報は表示されますが、AWS アカウントに関連する情報は表示されません。請求書には料金のみが記載され、その請求書が支払われたかどうかは示されません。
無料枠の通知
無料枠の制限に気づかずに使い続けることを防ぐために、アラート受信を設定しておきます。
「請求ダッシュボード」->「設定」の「無料利用枠の使用のアラートの受信」にチェックをします。
Amazon CloudWatchでAWS利用料金の監視
AWSは、利用料が発生しても、どんどん課金額が増えても通知してくれません。
CloudWatchを利用して、課金金額が予想を超える場合は、通知されるようにします。
「請求ダッシュボード」->「設定」から「請求アラートを受け取る」にチェックを入れ設定を保存します。
メニューから「CloudWatch」をクリックします。
請求金額は、バージニア北部に保存されているようなので、右上のリージョン設定をバージニア北部に変更します。
「請求」をクリックします。
「請求アラーム」の「アラームの作成」をクリックします。
「詳細表示」をクリックします。
「名前」、「説明」、「料金が次の時」の指定、「メールリスト」を入力し、「アラームの作成」をクリックします。
この時、料金の指定が誤らないようにしましょう。
今回は、$1を超えた場合に通知するように設定しました。
「EstimatedCharges > USD $1」
新しいメールアドレスを指定した場合、確認が作業があります。
メールアドレスに、下記メールが届いているので、「Confirm Subscription」をクリックしましょう。
確認できました。
アラームの画面で下記のように表示されればOKです。
下記でも詳細に紹介されています。
Amazon CloudWatchでAWS利用料金の監視追加
CloudWatchで$1の通知を作成しましたが、もう1つ上の段階の金額も設定します。
CloudWatchは1回のトリガー分だけ通知されるので、1回目の通知で気が付かなければそのまま使い続ける可能性があるためです。
先ほど作ったアラートを選択し、「アクセション」から「コピー」をクリックします。
「詳細表示」をクリックします。
今回は、$5で作成しました。
表示がされればOKです。
その他気を付けること
サービスを使う前には、課金の内容を確認する
1年無料枠ではありますが、何かサービスを使う前には課金の条件などを確認しておきましょう。しらずに1万円課金とかなきそうになります。
リージョンに注意する
リージョンに気を付けましょう。リージョンが変わると課金額も少し変動します。
あと、検証とかで遠いリージョンにするとまともな検証結果がえられない・・・etc。
小まめな停止・削除を心がける
検証後に放置して不要なはずの課金がされるケースが散見されます。
いらないものは停止・削除をしてきましょう。
ログインアカウントを使い分ける
ルートアカウントが最初に割り振られますが、普段の運用の中では権限を設定したIAMユーザーを使いましょう。
どのような方法が一番いいのか・・・は悩みどころですが。
大きく、管理権限・制限絞った操作権限・参照権限の3つのパターンでちょっと試し行ってみようかと画策中です。
小まめにサインアウトする
長すぎると思ったもののセッションが12時間残るっぽいです（これ、ほんとかなぁ）
詳細な調査は今後にしますが、セキュリティの観点から終わったらサインアウトがいいでしょう。（AWSに限った話ではありませんが・・・）
Q: セッションはいつ失効しますか?
AWS または IAM アカウント認証情報を使用して AWS マネジメントコンソールにサインインしてから 12 時間が経過すると、セキュリティのためにログインセッションが失効します。セッションが失効した後で作業を再開するには、[Click login to continue] ボタンをクリックし、再ログインしてください。再開したセッションの期間は、federation API（GetFederationToken または AssumeRole）および管理者の設定によって異なります。AWS アカウントへの一時アクセスを付与する安全な委任ソリューションの詳細については、Security Blog を参照してください。
アカウント・ファイルなどをちゃんと管理する
AWSでは、いろいろなアカウントやファイルを使う構成パターンが多くなりそうです。
アカウントやファイルの管理はきっちりと行っていきましょう。
まとめ
色々書きたいことはあったけど、とりあえず最初の一歩ということで最低限の部分試してみました。あとはサービスごとにコツコツ見ていきますかなぁ。
道のりは遠い・・・・。