AWSで認証・認可について学ぶ

みなさんこんにちは＆こんばんは、スカイアーチHRソリューションズ所属のyyktです。
今回初めての投稿となりますが、私が前職でAWS担当をしていた際に主に扱っていたセキュリティ項目から、特に分かりにくい認証と認可の違いについて説明します。

AWS（Amazon Web Services）とは

AWS（Amazon Web Services）は、クラウドコンピューティングサービスの大手プロバイダーです。AWSでは、認証と認可の仕組みが提供されており、それらを活用することでセキュリティを強化できます。

本記事では、AWSの認証・認可について解説し、その活用方法を紹介します。

認証と認可の基本概念

まずはじめに、認証と認可の基本的な概念について説明します。

認証の定義

認証(Authentication)とは、ユーザーが自分自身を特定するためのプロセスです。
具体的には、ユーザー名やパスワードなどの情報を提供し、システムがその正当性を確認することで、本人であることを証明します。
認証は、システムにアクセスする前の第一のステップであり、セキュリティの基盤となります。

認証を平たく言うと、以下の手順を踏みます。

その中でも最も採用されている認証方式は、やはりIDとパスワードの組み合わせによる認証でしょう。
アカウント作成時にユーザが独自に定義したIDとパスワードに基づき、その一致で本人であることを認証します。

もし入力されたID・パスワードが正しくない場合には、サーバは認証エラーを返します。
また、この時サーバから返されるエラーコードは「401」であることが多いです。

認可の定義

認可(Authorization)とは、認証されたユーザーがどのリソースにアクセスできるかを決定するプロセスです。
認可は、ユーザーのアクセス権限を制御し、リソースへの不正なアクセスを防ぐことができます。

先ほどと同じように平たく言うと、

①クライアントは、「システム上でこれこれをしたいんですが…」と、リクエストを送信します。

②サーバはそれを見て、「権限チェックするからちょっと待ってや」とそのクライアントに付与された権限をチェックします。

③権限チェックした結果、OKならば「OK、やってええで」と許可し、NGならば「何言ってんねん、あかんやろ」と拒否します。

こんな感じです。

厳密にはトークンの払い出しとかいろいろと処理はあるのですが、ここでは簡潔に流れをまとめています。

また、③で拒否された場合にはサーバから返されるエラーコードは「403」となります。

よくforbiddenとか、Access Deniedとか言われたことがありませんか？

このエラーは、まさしく403による権限不足を指し示すものです。

ちなみに

基本的には認証と認可はセットで用いられることが多いと思いますが、場合によっては認可のみを用いるパターンもあります。

たとえばですが、駅の改札なんていうのは認証を行わず認可のみを行っている例です。
改札では個人を特定するためのプロセス（認証）を行っていませんが、それに対して切符の購入をすることによって改札の通過をする許可（認可）が行われています。

AWSの認証・認可のサービス

最近では、自社システムをクラウド、特にAWSへ移行する流れが非常に大きなものとなっていますが、そのような場合にどのようにシステムに対して認証と認可のプロセスを提供することが出来るのでしょうか？
AWSでは、認証と認可をサポートするために、以下のようなサービスが提供されています。

AWS Identity and Access Management (IAM)

IAMは、AWSリソースへのアクセスを管理するためのサービスです。ユーザーやグループを作成し、それらに対してアクセス権限を付与することができます。

AWS Cognito

Cognitoは、ウェブアプリケーションやモバイルアプリケーションでのユーザー認証と認可を簡単に実装するためのサービスです。ソーシャルログインやMFA（Multi-Factor Authentication）にも対応しています。

次のセクションでは、それぞれのサービスについて詳しく見ていきましょう。

AWS Identity and Access Management(IAM)

AWS Identity and Access Management(以下、IAM)は、AWSの認証・認可を管理するための中心的なサービスです。ここでは、IAMの主要な機能について解説します。

IAMの主要な機能

1. ユーザー管理: IAMでは、ユーザーを作成し、それぞれにアクセス権限を付与することができます。
2. グループ管理: 複数のユーザーをまとめて管理するために、グループを作成できます。グループには、共通のアクセス権限を設定することができます。
3. ポリシー管理: ポリシーは、リソースへのアクセス許可を定義するドキュメントです。IAMでは、ポリシーを作成し、ユーザーやグループに割り当てることができます。
4. ロール管理: ロールは、AWSリソースに対するアクセス許可を一時的に付与する仕組みです。IAMでは、ロールを作成し、AWSリソースに割り当てることができます。

IAMにはここに記載されていない機能もたくさんあるのですが、主な機能は上記の4つです。

下記の図はIAMの利用イメージです。
まず初めに、各ユーザはそれぞれ払い出されたIAMユーザに基づいてID・パスワードを入力して認証を行います。
その後、ユーザに付与されたIAMパーミッション（ポリシー）の内容に基づいてアカウント内で決められた操作を行うことが可能になります。この図では、EC2とS3に対しての操作が可能であることを示します。

それぞれの管理は基本的にユーザ側に委ねられており、強い権限を付与するも弱い権限を付与するも、ユーザのさじ加減です。（AWS責任共有モデル）

しかし、AWSのベストプラクティスとしては「最小権限の原則」に基づいてそれぞれのエンティティに対して必要最小限の権限のみを付与することが良いとされています。

詳しくは、AWSの公式ブログの記事をご覧ください。

AWS Cognito

Amazon Cognitoは、モバイルアプリやウェブアプリの開発者がユーザー認証、認可、そしてデータの同期を簡単に行えるサービスです。
開発者はユーザーのサインアップとサインインプロセス、そしてユーザーデータのアクセス制御をCognitoに委ねることができます。

Cognitoは主に2つの主要なコンポーネントから構成されています。

1. ユーザープール: ユーザープールはユーザーディレクトリであり、アプリケーションのユーザーがサインアップしてサインインすることができます。ユーザープールには、ユーザープロファイルが保存され、ユーザーが自己登録し、サインインできます。また、SNSや企業のディレクトリなど、他のアイデンティティプロバイダからのサインインもサポートしています。
2. アイデンティティプール: アイデンティティプールは、アプリケーションユーザーに一時的なAWS資格情報を提供し、AWSサービスへの直接アクセスを可能にします。これにより、ユーザーはアプリケーションから直接、Amazon S3、DynamoDBなどのAWSリソースにアクセスできます。

Cognitoを使用することで、開発者はユーザー管理とデータ同期のためのバックエンドロジックを作成する手間を省き、より重要なアプリケーションのビジネスロジックに集中できます。
また、Cognitoはセキュリティについても優れており、ユーザーデータの暗号化、パスワードの安全なハンドリング、MFA（多要素認証）、ユーザーブロックなどの機能を提供します。

AWS上にサービスを構築する場合、その認証・認可のシステムを構築するには様々なアーキテクチャが考えられますが、Amazon Cognitoを利用することでシンプルかつ少ない工数で認証・認可プロセスを実現できます。

以下は、Amazon Cognitoを利用したアーキテクチャの一例です。
（引用元：https://aws.amazon.com/jp/blogs/architecture/throttling-a-tiered-multi-tenant-rest-api-at-scale-using-api-gateway-part-2/）

上図のアーキテクチャでは、システムのAdministratorがCognitoへの認証を行い、その結果払い出されたJWT Tokenを利用してAPI Gatewayへのadminアクセスを行っています。

まとめ

この記事では、情報セキュリティにおける認証と認可の違いを説明するとともに、AWS上でそのプロセスを提供するサービスであるIAMとCognitoについて説明しました。

先に示した通り責任共有モデル上のアクセス制御はユーザ責任となるため、もし万が一にでも不正アクセスなどによる被害が発生した場合には多大なる損害を被る可能性は否めません。

これはAWSやAzureなどのクラウドに限らず、システムを構築する際は慎重に要件を定義したうえで、それぞれのエンティティに対して適切な権限を付与し制御することが肝要と言えるでしょう。