介護要因系アラフィフ未経験転職者２年生の…「いとあたらし」です。
当初は慣れない操作等に苦労しましたが、周りの方には面倒見のいい方が多く、いろいろな経験を積むことができ、かなり慣れる事ができました。
業務中の空き時間には自己学習も可能な環境ですので、パソコンの操作や、処理の待ち時間が苦にならない人には、非常にいい職場だと思います。
はじめに
前回のIAMハンズオンに記載した通り、ハンズオンの内容は、最初から最後までスルーすることなく全て網羅してゆく方向でやってみます。
…ということで、今回はセキュリティ対策におけるハンズオンをやってみました。
サーバーを立てる以上は、こうした地道な設定等を実施して、常にセキュリティを意識した環境構築を念頭にしてやっていこうと思います。
今回はハンズオン編①です。
やってみました
[AWS Hands-on for Beginners – Security #1]
～AWSアカウント作成後すぐやるセキュリティ対策
03 IDアクセス権管理(1)
・不必要な権限を付与していると、情報の流出や破壊、不正閲覧や改ざん、不正使用、サービス自体の中断などが起こる場合があります。
・特権アカウントは厳重に管理し、利用者へ与える権限は必要最小限に絞って、アカウントへの不正アクセス対策を実施することが、アクセス権管理の基本となります。
そこで今回から2回に分けてIDアクセス権管理について実施します。
まずは、ルートユーザーの多要素認証(MFA)を有効化し、アクセスキーを削除してルートユーザーを保護しましょう。
AWS Identity and Access Management (AWS IAM)で管理してゆきます。
・各AWSリソースに対して、別々のアクセス権限をユーザー毎に付与できます。
・多要素認証(Multi-Factor Authentication：MFA)によるセキュリティの強化が可能です。
・一時的な認証トークンを用いて権限を委任できます。
・他のIDプロバイダーで認証されたユーザーにAWSリソースへの一時的なアクセスを許可することができます。
・世界中のAWSリージョンで同じアイデンティティと権限を利用可能にすることも可能です。(データ変更は結果整合性を保ちながら全リージョンへ伝搬します。)
・AWS IAM自体は無料で利用できます。
AWSに実際にログインしてゆくユーザーは大きく分けて以下の２種類となっております。
1． ルートユーザー
→メールアドレス＋パスワードでログインします。
→AWSサービスとリソースに対して完全なアクセス権限を有しています。
2． IAMユーザー
→アカウントID＋IAMユーザー名＋パスワードでログインします。
→紐づいているIAMポリシー権限で許可された操作のみ可能となります。
→利用者ごとにIAMユーザーを作成し、利用者はそのユーザーでログインし、作業を進めていく運用形態となっています。
※ルートユーザーの認証が必要なAWSタスクの例
・ルートユーザーのメールアドレスやパスワードの変更
・IAMユーザーによる課金情報へのアクセスのActivate/Deactivateの設定
・支払オプションの変更
・AWSサポートプランの変更
・IAMユーザーへのアクセス許可のリストア(初期化)
・無効な制約を設定したAmazon S3バケットポリシーの修正
・脆弱性診断フォームの提出
・坂引きDNS申請
・CloudFrontキーペアの作成
・AWSアカウントの解約
(参考資料)AWSアカウントのルートユーザー認証情報が必要なAWSタスク
※講座のURLリンク先は現在見れなくなっており、以下のリンク先に変更されたようです。
※IAMユーザーのイメージについて
→使用するAWSサービスはAmazon EC2及びAmazon S3とした場合の事例
・管理者グループ
→EC2インスタンスに対するすべての操作が可能。
→S3バケットに対しても、表示・作成・削除の操作が可能
・運用者グループ
→EC2インスタンスの参照のみ可能だが削除の操作はできません。
→S3バケットに対しては表示する事のみ可能ですが、作成や削除はできません。
尚、これまでのIAMに関する内容に関しては、私の以下の過去のハンズオンブログも参照いただくと、一層よく分かっていただけると思われます。
…ただし、めっちゃ長いのでリンク先の読破は気合を入れて取り組んでください(;’∀’)
今回のハンズオンですること
1.ルートユーザーの多要素認証の有効化
2.ルートユーザーのアクセスキーの削除
3.IAMパスワードポリシーの適用
では、やってみます。
(準備)
ルートユーザーにて、AWSマネジメントコンソールを開きログインします。
ログインに成功すると以下のような画面が開きますので、右上のリージョン選択部分で、米国東部(バージニア北部)を選択します。
正しく選択すると、上部表示が以下のようになります。
※この時、何故、最寄りの東京リージョンではなく、バージニア北部リージョンを選択するのかについてですが、講義では無かったのですが、調べてみました。
→AWSのサービスの数は、us-east-1 米国東部（バージニア北部）が一番多く、新しい機能のリリースも、このリージョンが最初に対象となる傾向にあります。ただし、その分バグが発生し、障害が起きる可能性も上がるそうです。
→リージョンによってコストが異なり、一番安いのは米国の3つのリージョン (バージニア北部・オハイオ・オレゴン) です。一方で、東京リージョンはそれらより約31%も高いです。日本にいる利用者に関して言えば、料金が高くてもレスポンスタイムを重視するなら東京を選ぶのが良いそうです。
ちなみに、AWSのリージョンの中でも、米国東部(バージニア北部)は特別なリージョンとして他のリージョンとは一線を画しています。例えば、コンテンツ配信ネットワーク(contents delivery network: CDN)を提供するサービスであるAmazon CloudFrontでHTTPSアクセスの設定を行う場合、AWS Certificate Managerによって作成されたSSL証明書を指定できますが、米国東部(バージニア北部)リージョンで作成されたものに限定されます。また、新しく登場したサービスが米国東部(バージニア北部)リージョンでいち早く利用可能になることも多く、特に理由がなければ米国東部(バージニア北部)リージョンを選ぶことが推奨されているそうです。
以上より、今回は必要となるサービスの有無というAWSの機能との兼ね合いで、バージニア北部リージョンの指定としているようです。
ちなみに、バージニア北部リージョンに有って、東京リージョンに無いサービスが、今回のハンズオンの内容からすると、少なくとも以下の2つのサービスは該当するようです。
・AWS Cost Explorer
・AWS Cost and Usage Report
尚、現時点でのAWSリージョンごとのサービス内容詳細は以下にて確認できるようです。
日本国内での使用だから、東京リージョンだとレスポンスが早いから、必ずしも東京リージョン選択でOKっていう訳ではないんですね～。
1. ルートユーザーの多要素認証の有効化
まず、先程開いたコンソール画面より、IAMのサービスを開きます。
…どうやら、いきなり早速講義に出ていた画面と、表示内容が異なっているようです( ﾟДﾟ)
以降やってゆくことは、同じっぽいので、とりあえずこのまま進めてみましょう。(;^_^)
まず…[MFAを追加]のボタンをクリックします。
以下のセキュリティ認証情報の画面に遷移しますので、再度以下の[MFAを追加]のボタンをクリックします。
良かったぁ～！ここでまた講義の画面遷移と一致する状態になっているようです。(*’▽’)
クリックすると以下の画面が表示されます。
今回は、仮想MFAデバイスを使用します。
→スマホ等にインストールして使用するタイプの仮想MFAデバイスです。
講義では、名前の事は出てきませんでしたが、現在は名前を決める必要が有るようです。
私は、「k_atarashi-MFA」という名前にしてみます。
以下の画面より、[続行]してみます。
以下のようなリンクが表示されましたので…
通常は、[互換性のあるアプリケーションのリスト]を参照するでしょうが…
QRコード読み取りアプリはそんなに読み取りに差は無いと考えましたので、既に、私の個人スマホに入っている「QRスキャナー」というアプリで読み取ってみます。
…読み取れない時は、その時考えます(*‘ω‘ *)
…と、ちゃんと読み取れました！
先程の画面を下にスクロールするとMFAコード2の入力欄も表示されますので、読み取った数字を6桁づつ2回に分けて入力してゆき、[MFAの割り当て]ボタンをクリックします。
どぉだぁ！
あれれ～～～( ;∀;)やっちゃいました。
皆さんは、こうならないようにちゃんと[互換性のあるアプリケーションのリスト]を参照してからやりましょうね！
とりあえず、気を取り直して、Duo Mobileというアプリをスマホにインストールして、もう一度やってみます。
…どうやら、アプリ上でカウントダウンしながら、30秒ごとに6桁の数字が表示されるので、その連続する2回分を入力する必要が有るようです。
単純なQRコード読み取りだけでは表示されない内容でした(;’∀’)
さすがは、AWSのセキュリティ…( ﾟДﾟ)
無事、入力が完了すると以下のようなサインイン成功のダイアログが表示されました。
[閉じる]ボタンをクリックすると無事MFAの設定はできたようです。
2.ルートユーザーのアクセスキーの削除
アクセスキー(アクセスIDとシークレットアクセスキー)をクリックすると以下のような画面となります。
現時点での私のアカウントには、作成済のアクセスキーが表示されないので、この操作は不要だったようです。
3.IAMパスワードポリシーの適用
画面左ペインの[アカウント設定]をクリックします。
すると、以下のような画面に遷移しますので、[パスワードポリシーを変更する]のボタンをクリックしてみます。
すると、以下のような設定画面が表示されます。
いろいろパスワードを難しくすることも可能な事が分かりますが、学習用アカウントなので、現時点では、現状維持で、パスワードポリシーの変更はキャンセルとしてあります。
一通りの設定が完了しましたので、一旦IAMのダッシュボードに戻ってみます。
ダッシュボードの表示で当初赤い注意マークがでていた部分が、緑色のチェックマークになりました。
04 IDアクセス権管理(2)
今回は、ルートユーザーの代わりとなるユーザーを作成してゆきます。
・IAMユーザー
→AWS操作用のユーザー
・IAMグループ
→IAMユーザーをまとめるグループ
・IAMポリシー
→AWSのサービス操作に対する権限設定、IAMユーザーやIAMグループに対して付与できます。
・IAMロール
→AWSサービスやアプリケーション等のエンティティ(一つの物事を表すひとまとまりのデータの集合)に対して、AWSリソースの操作権限を付与するための仕組みです。
IAMユーザー、グループ、ポリシー、ロールのイメージは大きく分けて2通り
・直接IAMポリシーを付与するパターン
・IAMグループにIAMポリシーを付与し、IAMユーザーがそれに属するパターン
今回は、後者のパターンにてIAMを作成します。
(実施すること)
※ルートユーザーで作業してゆきます。
1.事前定義されたIAMポリシーの確認
2.IAMグループの作成
3.IAMユーザーの作成
4.IAMユーザーのMFA有効化
5.IAMユーザー/ロールによる請求情報へのアクセス
1.事前定義されたIAMポリシーの確認
まず、ルートユーザーでコンソールにログインし、リージョンがバージニア北部となっている事を確認します。
IAMのサービスコンソールへ移動します。
まず、左側ペインのポリシーを選択します。
以下のように、標準で定義されているポリシー一覧が表示されます。
今回は、AdministratorAccessを選択しますが、その前に文字をクリックするとポリシーの詳細が確認できます。
まず、概要の詳細が確認できます。JSONボタンをクリックすると、JSON形式のポリシー内容を確認できます。
JSONは以下のように表示されます。
以上で、事前定義されたIAMポリシーの確認までは完了です。
2.IAMグループの作成
次に、左側ペインのユーザーグループを選択します。
遷移した画面から[グループを作成]のボタンをクリックします。
以下のような画面となりますので、講義に従い、admin-group名で進めてゆきます。
下にスクロールして、ポリシーを設定します。
今回は、AdministratorAccessのポリシーを付与してゆきます。
下にスクロールして、[グループを作成]ボタンをクリックします。
以下のように、admin-groupというグループが作成されましたと表示されます。
ここまでで、グループの作成は完了です。
3.IAMユーザーの作成
引き続きIAMユーザーを作成してゆきます。
まず、左側ペインのユーザーグループを選択します。
以下のような画面に遷移します。
今回また新たにIAMを作成してみますので、[ユーザーを追加]ボタンをクリックします。
ユーザーを追加という画面に遷移しますので、以下のように設定して進めます。
次のステップに進み、以下のように設定し次のステップに進みます。
タグに関しては、今回特に必要無いので、空白のまま次のステップに進みます。
すると、以下のような確認画面に遷移しますので、[ユーザーの作成]ボタンをクリックします。
すると、以下のようにユーザーの作成が成功した旨の詳細画面が表示されます。
この画面でいろいろなやり方が有るのですが…私は簡単に記録に残せる[.csvのダウンロード]ボタンをいつもクリックしています。
ここまで完了したら、右下の[閉じる]ボタンをクリックします。
すると、以下のような画面に遷移して、正常にユーザーが作成されている事を確認できます。
尚、今回作成したIAMユーザーのMFAは「なし」の状態も確認できます。
4.IAMユーザーのMFA有効化
次に、作成したIAMユーザーのMFA(多段階認証)を有効化してゆきます。
まず、画面赤枠のユーザー名の部分をクリックします。
以下の画面に遷移しますので、認証情報タブをクリックします。
すると、次のような画面が表示されますので、[MFAデバイスの割り当て]ボタンをクリックします。
次のような画面が表示されますので、以降は、少し前にやらかした…( ;∀;)
箇所のやらかした部分を省いた対応をしてゆくと、IAMのMFAデバイス割り当ても完了となります。
※今回、名前は「MFA-user」としてあります。
以下のような画面が表示されたら、IAMのMFAデバイス割り当て完了となります。
5.IAMユーザー/ロールによる請求情報へのアクセス
[ctrl]キーを押しながら、右上の[アカウント]を選択し、別ウインドウでコンソールを開きます。
以下のような画面が開きますので、下の方へスクロールします。
以下のような項目がありますので、[編集]リンクをクリックします。
以下のような画面となりますので、赤枠内の「IAMアクセスのアクティブ化」にチェックを入れて、[更新]ボタンをクリックします。
以下のような画面が表示されれば、IAMユーザー/ロールによる請求情報へのアクセス設定は完了となります。
元のコンソールに戻って、サインアウトし、[もう一度ログインする]をクリックします。
今度は、IAMユーザーでサインインしなおします。
サインイン時に、MFA認証を聞かれますので、正しく登録すると以下のような画面が表示されます。
以上で、今回のハンズオンは終わりです…が、かなり長くなったので、やはり、ハンズオンに関しては、分割して続編を作ってゆく必要ができてしまいました。
終わりに
今回は、セキュリティ#1ハンズオン編①ということとなりました。
AWSのセキュリティ設定に関して、いろいろやってみた訳ですが…
さすがは、AWSのセキュリティ…( ﾟДﾟ)
仮想MFAに使用するモバイルデバイスの互換性のあるアプリケーションとは、単純なQRコードを読み取れるアプリという訳でなく…ちゃんとMFAコードが表示する事ができるアプリが必要な事は、とても勉強になりました。
あと、今回、講師の方は触れていなかったのですが…リージョンについて、いろいろ調べてみると、使用できるサービスやコストに差が出てくることも分かりましたので、いい経験ができたと思います。
しかしながら…こんなに大変だったのに、まだまだハンズオン編も序盤までしか進めていなかったようです…( ;∀;)
まだまだ、いろいろやらかしながら、じっくり時間をかけて学習してものにしてゆきたいと思います。
長らくのお付き合いを有難うございました。m(_ _)m
コメント