【AWS】AWSのアクセス権について

Posted at 2024-09-22

前回までのあらすじ

第1回目の学習ではクラウドサービスとはなんなのかをAWSが公式で紹介しているサイトについてまとめました。今回からは実際にAWSの中身を詳しくみていこうと思います。

IAMについて

IAMとはAWSにおける認証機能であり、セキュリティー面を考慮する上で必要不可欠なものになります。
AWS公式サイトによると以下のように説明があります。

AWS Identity and Access Management (IAM) は、AWS リソースへのアクセスを安全に管理するためのウェブサービスです。IAM を使用すると、ユーザーがアクセスできる AWS のリソースを制御するアクセス許可を管理できます。IAM を使用して、誰を認証 (サインイン) し、誰にリソースの使用を認可する (アクセス許可を付与する) かを制御します。IAM は、AWS アカウントの認証と認可を制御するために必要なインフラストラクチャを提供します。

簡単に言えば、特定の個人に対してAWSリソースへのアクセスを許可することで、必要な機能だけにアクセスできるようにすることができるというものになります。

IAMの仕組み

IAMでは認証、認可を管理することでアクセスの制御を行っています。

認証とは

ユーザーやシステムが「誰であるか」を確認するプロセスです。つまり、本人確認の手続きです。認証により、システムはアクセスを試みている者が主張している本人であるかどうかを確認します。

これをさらに簡素化していうと、誰であるかを確認し、本人かどうかを見ることです。

具体例

皆さんが何かしらのサイトにアクセスし、ログインをしたいとします。ログインをする時には大体、ユーザー名とパスワードを入力します。正しく入力をすることができると自分のマイページであったり、購入履歴などの確認ができるようになります。

この動作の中でユーザー名とパスワードを入力が認証にあたります。今回の例ではユーザー名とパスワードを通して、誰であるかを確認していると言うことです。

認証の方法(ChatGPTさんより)

パスワード認証: ユーザー名とパスワードの組み合わせで認証します。最も一般的な方法です。
多要素認証（MFA）: パスワードに加えて、別の要素（携帯電話のSMS、認証アプリ、ハードウェアトークンなど）を使って追加のセキュリティを提供します。
バイオメトリクス認証: 指紋、顔認証、声認証など、生体情報を使って認証を行います。
OAuthやSSO（シングルサインオン）: 外部の認証プロバイダー（GoogleやFacebookなど）を使って、認証情報を一度だけ提供することで複数のシステムにアクセスできる方法です。

認可とは

認証が成功した後に、認証されたユーザーが「何をできるか」を決定するプロセスです。認可では、ユーザーやシステムが特定のリソースや機能に対してどのような操作を行えるかを定義します。

これをさらに簡素化していると、リソースへのアクセス許可や操作権限を与えることです。

具体例

皆さんが記事投稿サイトに認証をし、自分のアカウントでログインをしました。ログイン後、色々な記事を見ていたときに自分とは別の人が書いた記事に間違えを見つけました。実際にその記事を編集し、正しい文章に修正しました。

これを見たとき違和感を感じる人の方が多いと思います。「人が書いた記事を勝手に編集！？そんなのできないだろ！！」となると思います。これが認可です。一般的な記事投稿サイトであれば、自分が書いた記事を編集できるが、他人が書いた記事まで編集はできません。これは、ユーザーに対して「このアカウントだったら、この記事（自分の記事）を編集してもいいよ」という認可が与えられています。

認可の方法(ChatGPTさんより)

アクセス制御リスト（ACL）: 特定のユーザーやグループに対して、どのリソースにアクセスできるか、またどの操作を許可するかをリストで管理します。
ロールベースアクセス制御（RBAC）: ユーザーに役割（ロール）を割り当て、そのロールに基づいてアクセス権限を管理します。
ポリシー: AWS IAMなどで使われるポリシーのように、リソースに対する操作権限を詳細に定義したルールを使用して管理します。

IAMの機能

IAMで用いられる機能として「IAMユーザー」「IAMロール」「IAMグループ」「IAMポリシー」があります。１つずつ確認します。

IAMユーザー

AWSアカウント内でリソースにアクセスするための個別のアカウントです。IAMユーザーにはそれぞれ個別の認証認可があり、必要最低限の機能を、必要な人だけに渡して運用することが求められます。

認証方法

AWSマネジメントコンソールへのアクセス（パスワード）
パスワードはAWSマネジメントコンソールにログインする際に使用するもので、ユーザー名およびパスワードで認証します。AWSマネジメントコンソールはAWSのリソースやサービスを管理するためのユーザーインターフェースです。
プログラムによるアクセス（アクセスキー）
アクセスキーはIAMユーザーがアプリケーションからAWSのサービスにアクセスする際に使用する認証情報です。作成時にはアクセスキーIDおよびシークレットアクセスキーの2種類が発行され、この2種類のキー情報があれば、場所を問わず、AWSを操作できる仕組みになっています。
（例）個人PCからIAM ユーザーと同じ権限を持つことができ、遠隔操作でEC2などのインスタンスを作成することが可能となります。

こちらから引用させていただきました。

IAMロール

特定の権限を持つ一時的な認証情報を提供するための仕組みです。IAMユーザーと異なり、IAMロールには固定された認証情報がなく、ユーザーやAWSサービスが必要に応じてロールを引き受け、リソースにアクセスします。

IAMロールの仕組み

私自身で説明できれば良かったのですが、こちらを見ていただいた方がわかりやすいかと思ったのでURLぶん投げで、説明を終わりたいと思います。

IAMグループとIAMポリシー

IAMグループとIAMポリシーをまとめた理由としては使用用途が似ているからです。こちらの2つの機能は権限を与える際にユーザーやロールの設定を効率的に管理するために利用されます。

IAMグループ

複数のIAMユーザーをまとめるためのコンテナです。IAMグループにポリシーを設定することで、グループ内のすべてのユーザーに共通の権限を付与できます。つまり、そのグループに登録されているメンバーには同じ認可があるということになります。

ポリシーという言葉が出てきましたが、これが認可情報になります。こちらの設定をするのがIMAポリシーになっているのでそちらを見てみましょう。

IAMポリシー

IAMユーザー、IAMロール、IAMグループに対して、どのAWSリソースにどのような操作を許可するかを定義するルールです。ポリシーはJSON形式で記述され、詳細にアクセス権限を管理できます。1つのポリシーは1人~複数人に対して設定できます。また、権限の設定を変更したい時もポリシーを付け替えたり、変更するだけで、結びつくユーザーやロールに対して適応することができます。

IAMポリシーの設定

2つの視点からポリシーが設定できるようになっており、実行者側の視点と実行される側の視点で分かれています。

アイデンティティーベースのポリシー
実行者側の視点になります。実行者が「何に対して何ができるのか」を設定するものです。
例: ユーザーA（実行者側）がDB（実行される側）の追加、編集、削除ができる。
リソースベースのポリシー
実行される側の視点になります。実行される側が「何を許可するか」を設定するものです。
例: このファイルの編集を許可する。

IAMポリシーの設定はオリジナルのものを作成すること（カスタムポリシー）が可能ですが、すでに用意されているポリシー（AWS管理ポリシー）を使った方が設定ミスがなく、安全です。