LoginSignup
0

posted at

updated at

入社3年目、業務以外の知識がない自分がGWを捧げてサービス・アプリケーションを勉強してみた!〜1日目AWS:IAMユーザ作成・前編〜

はじめに

前記事(https://qiita.com/hugo-crt/items/3cebbbf16db1d2fde063)
の続きです。

今回はrootユーザ登録後設定したいセキュリティ対策についてです。
セキュリティに関するドキュメントは膨大な情報量なので基本的な点だけかいつまんでいこうと思います。

必要なもの

  • スマートフォン
  • 以下認証アプリケーションのいずれか(今回はMicrosoft Authenticatorを使用します)
    スクリーンショット 2022-04-29 17.28.51.png

責任共有モデル

責任共有モデルとは、AWSが提示している責任の所在を表したものです。
以下の画像になります。
Shared_Responsibility_Model_V2_JP.a4acd9721218c9d7d4ab5083c349e706e8ad300d.jpeg

有名なやつですね。
要はオンプレ(実際に配置されているサーバやストレージなど)で表すところの基盤に関してはAWSが提供しているため、責任の所在はAWSにあります。
対して我々のようなユーザはその基盤を利用してサービスを立ち上げる際、セキュリティ対策や顧客データなどを外敵から守ることが使命となります。

自社ビルで考えてみます。
自社ビルは会社が所有している物件であるため、貸し手に対して電気・水道・インターネットの環境に関しては管理責任があります。

そのため、停電や断水のような不測の事態で借り手に迷惑がかからないよう、安全管理を行います。
他にも、いつもはインターネットの回線速度が高速であったのに、急に低速になって仕事にならない、といったことも避けなければなりません。

もちろん、設備不良で借り手に損害など被った際は、損害賠償問題につながることもあるでしょう。
したがって、提供しているものが不変の状態であることに対して責任を持っているのですね。

可用性というと不変の要素の一つにしかすぎないため適切ではないと思いますが、「いつでも繋がり、常に同じ動作であること」のようなイメージを持ちました。

ちなみにAWSが提示している責任共有モデルの解説は以下になります。
https://aws.amazon.com/jp/compliance/shared-responsibility-model/

IAM(Identity and Access Management)とは

責任共有モデルの章では、ユーザはサービスの外部に対するセキュリティ対策に責任があると書きました。

このような不正アクセスを防止するために、ユーザ内でも責任の所在を切り分ける必要があります。
ユーザ登録編で登録したrootユーザはいわゆる 神ユーザ であり、AWSで利用している全サービスにアクセス権限を持ちます。
そのため、一度rootユーザに対して不正にアクセスされてしまうと、
閻魔大王様ユーザ へと進化してしまうわけです(いい例えが見つからなかった・・・)。

そのため、IAMではユーザごとに作業できる範囲を限定することで、悪魔ユーザ を生み出さないよう、
権限は最小限に というコンセプトをもっているようです。

会社と同じですね。
全決定権は社長などの上層部の役員が持ち、
〇〇長は自分の受け持っているチームやプロジェクトに対して責任を負い、
一般社員は自分の仕事に責任を持つ、みたいな。

rootユーザとIAMユーザの違いは以下の通りです。

rootユーザ

  • メールアドレス+パスワードでサインイン
  • フルアクセス権限を持つ
  • 作業用アカウントではない

IAMユーザ

  • アカウントID+IAMユーザ名+パスワードでログイン
  • IAMポリシー権限で許可された範囲のみ操作可能
  • サービスの利用者(≒作業者)ごとに作成する(推奨)

その他細かい違いはありますが、初学者としてはここまで知っておけばいいのかなと思います。
最初は広く浅く知っておいて、利用して徐々に知っていく的な。

ちなみにこんな使い方をするようです。
誰(どのユーザ)がどんなサービスに対してアクセスできるか、を割り当てます。
スクリーンショット 2022-04-29 17.03.13.png

IAM:rootユーザの設定

それでは実際にハンズオンを行なっていきます。

  • お好きなブラウザからAWSマネジメントコンソールを検索しクリックします。
    スクリーンショット 2022-04-29 16.08.24.png

  • 画面右上の「コンソールにサインイン」をクリックしてコンソール画面を開きます。

  • ログイン画面が出るかもしれませんが、今回は割愛します。
    スクリーンショット 2022-04-29 16.08.33.png

  • 画面上部のサービス検索窓からIAMを検索し開きます(最近アクセスしたサービスにあればそれでもOK)。
    スクリーンショット 2022-04-29 16.09.34.png

  • IAMダッシュボードに遷移します。初めてアカウントを作成してIAMを利用する方は自分のように、警告マークがついているのはMFA認証のみなのではないでしょうか。

  • 画面右側の「MFAを追加」をクリックします。
    スクリーンショット 2022-04-29 16.12.11.png

  • こんな画面に遷移するので、多要素認証(MFA)から「MFAの有効化」をクリックします。
    スクリーンショット 2022-04-29 16.12.39.png

  • 割り当てるタイプは今回仮想MFAデバイスを選択し「続行」をクリックします。
    スクリーンショット 2022-04-29 16.12.47.png

  • 「QRコードを表示」をクリックし、お持ちのスマートフォンの認証アプリケーションからQRコードを読み込みます。

  • MFAコードを入力したら「MFAの割り当て」をクリックします。

  • 連続する2つのMFAコードについては、以下の記事が参考になります
    (ここでちょっと詰まった、一気に2つ認証コード出ないじゃん!!)。
    https://qiita.com/Catetin0310/items/b91ea87f0ac8ea2f6b2b
    スクリーンショット 2022-04-29 16.13.28.png
    スクリーンショット 2022-04-29 16.20.45.png

  • ちょっと見切れていて申し訳ないですが、画面左下のアカウント設定をクリックします。
    スクリーンショット 2022-04-29 16.22.24.png

  • ついでにパスワードポリシーも変更しちゃいましょう。

  • 「パスワードポリシー」をクリックしてください。
    パスワードポリシーとは、言葉の通りパスワードを設定する際のルールです。
    何文字だとか、大文字が必要だとか。
    スクリーンショット 2022-04-29 16.22.48.png

  • ハンズオンの講師は以下の設定にしてたので、チェックを入れて各値入力して「変更の保存」をクリックします。
    スクリーンショット 2022-04-29 16.23.41.png
    スクリーンショット 2022-04-29 16.23.54.png

  • 画面左側のダッシュボードをクリックして、警告マークが外れているか確認しましょう。
    スクリーンショット 2022-04-29 16.24.11.png

緑色のチェックマークに変わりました。問題なさそうですね。
スクリーンショット 2022-04-29 16.24.21.png

最後に

正直ハンズオンを行うより記事書いてる時間の方が長い・・・
あとキーボード買い替えたい。それなりの値段するけど打ちづらい。
どなたか白・灰色系で手首に負担の少ないキーボード知ってますか。
やっぱりHHKBとかREALFORCEですか。そうですか。
貯金します・・・。

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
What you can do with signing up
0