- はじめに
- Amazon QuickSightとはどんなサービスなのか
- Amazon QuickSightのユーザー管理方法
- Amazon QuickSightにおける権限について
- Amazon QuickSightにおけるアセットへのアクセス管理について
- おわりに
はじめに
こんにちは。新卒入社2年目の大林です。今回は、「Amazon QuickSightのユーザー管理とアクセス管理について考えてみる」というテーマでブログを書いていきたいと思います。 AWSが提供するサーバレスなビジネスインテリジェンスツールであるAmazon QuickSightを使用することで、蓄積した膨大なデータの中から効率よく有益な情報を見つけ出し、迅速に意思決定を行うことに繋げやすくなります。Amazon QuickSightは便利なツールである一方で、データへのアクセス管理が適切に行われていなければ意図しない情報をユーザーに公開してしまいます。 本ブログでは、Amazon QuickSightの基本的な概要から、ユーザーの管理方法、アセットへのアクセス管理方法を紹介していきます。
Amazon QuickSightとはどんなサービスなのか
Amazon QuickSightとは
QuickSightは、AWSが提供するサーバレスなBIツールで、以下の画像に表示されているようなダッシュボードを作成することができます。 このダッシュボードはCloudFrontのログデータをもとに作成しています。 左のダッシュボードでは、ロケーションごとのデータ量を表しています。右のダッシュボードは、CloudFrontのディストリビューションごとにステータスをカウントしたグラフを表示しています。どちらのダッシュボードにおいても、データをグラフ化することで分析がしやすくなっていると思います。このように、QuickSightを使用してログデータなどの羅列された情報をグラフ化して、分析することで得られた情報をもとに次の対策を立てやすくなります。 また、QuickSightは作成したダッシュボードをアプリケーションに埋め込むことができたり、MLによる異常検出や予測、多様なデータソースとの統合、低コストから始めることできるなどの特徴があります。
Amazon QuickSightの構造
データソースにはファイルデータだとCLFやJSONなどを使用することができ、AWSサービスであればAmazon RedshiftやAmazon Athena、Amazon S3などを使用することができます。 また、QuickSightのデータソースにはSaaSを使用することもできます。 データソースをもとにデータセットを作成します。データセットは、データソースから必要な情報を選択して分析に適した形に整えられたデータの集合のことです。 データセットの枠に書いてあるSPICEとは、インメモリ型の高速なデータベースのことです。 SPICEを使用することで、PCなどに保存されているファイルのデータからデータセットを作成することができます。 作成されたデータセットをもとに上記のダッシュボードを作成することができます。
Amazon QuickSightのユーザー管理方法
ユーザー管理にはメールアドレスを使用した管理、AWS IAM Identity Centerを使用した管理、そしてActive Directoryと連携した管理方法があります。 状況に応じて、QuickSightの運用方法を決めていく必要があります。
メールアドレスを使用した管理方法
- メールアドレスでのユーザー管理
- 小規模な運用に適している →規模が大きくなると運用負荷が増加
AWS IAM Identity Center を使用した管理方法
- IAMを使用したユーザー管理
- SAML 2.0によるフェデレーションとSSO
- 中規模以上の環境での運用に適している
Active Directoryと連携した管理方法
- 組織で採用しているアプリケーションがMicrosoft Active Directoryと連携している場合、QuickSightを含むアプリケーションに対して一元的なユーザーアカウント管理ができる
- AWS Managed Microsoft Active Directoryが必要である
Amazon QuickSightにおける権限について
QuickSightの権限は、管理者、作成者、閲覧者の3つがあります。 データへの適切な操作権限をユーザーに設定することは、QuickSightを運用をする上で非常に重要になってきます。
権限の種類
管理者 (Admin)
- QuickSightのすべての側面にアクセスできる
- ユーザーやSPICE容量の管理が可能
- 他のユーザータイプ（AuthorとReader）の権限もある
作成者 (Author)
- データソースの定義やデータセットの作成が可能
- ダッシュボードの作成や共有が可能
閲覧者 (Reader)
- ダッシュボードの閲覧のみが可能な最も低い権限
カスタムアクセス許可
カスタムアクセス制限を設定できる条件
QuickSightのユースケースとして、ある作成者権限を持ったユーザーには、データソースの定義やデータセットの作成を許可して、 別の作成者権限が付与されているユーザーにはデータソースの定義はさせたくないといった場合が出てくると思います。 そのような場合に有効なのが、カスタムアクセス許可です。 カスタムアクセス許可は、ユーザーやロールに関連付けることができるより細かいアクセス制御をするための設定です。 注意点として、カスタムアクセス許可を作成できるのは管理者権限を設定されているユーザーで、 カスタムアクセス許可を設定する対象のユーザーはIAMで管理されたユーザーである必要があります。
ユーザーにカスタムアクセス許可を関連付ける
カスタムアクセス許可はマネジメントコンソール上から作成することはできますが、ユーザーに関連付けるときはCLIで設定する必要があります。 CLI実行時には、「custom-permissions-name」でユーザーに設定したいカスタムアクセス許可を指定する必要があります。
aws quicksight update-user \ --user-name ユーザー名\ --role 権限名 \ --custom-permissions-name カスタムアクセス許可名 \ --email メールアドレス \ --aws-account-id アカウントID \ --namespace default \
実行結果
以下画像の実行結果は、test-restrictという名前のカスタムアクセス許可をユーザーに設定した場合のレスポンスです。 レスポンスの結果を見ると、「CustomPermissionsName」の欄に設定したカスタムアクセス許可の名前が確認できます。
マネジメントコンソール上で、ユーザーのアクセス許可の部分を確認すると、 CLIで設定したtest-restrictという名前のカスタムアクセス許可がユーザーに設定されていることを確認することができます。
Amazon QuickSightにおけるアセットへのアクセス管理について
共有フォルダ
Amazon QuickSightの共有フォルダ機能により、チームや組織内でダッシュボードやデータセットを簡単に共有して、管理することが可能になります。 以下の図をもとに説明すると、閲覧者Aには共有フォルダAと共有フォルダBにアクセスすることを許可していますが、 閲覧者Bには共有フォルダCへのアクセスを許可して、共有フォルダBへのアクセスは許可していません。 このように、特定のユーザーのみにダッシュボードやデータセットを共有する場合に共有フォルダは有効です。
共有フォルダへのアクセスをユーザー一人ひとり許可していった場合、かなり作業時間がかかると予想できます。 そういったケースには、グループ単位で共有フォルダへのアクセスを許可すると運用効率が上がります。
共有フォルダはマネジメントコンソール上から作成することができます。 サイドバーから共有フォルダをクリックして、画面右上の「新しいフォルダ」から作成することができます。
制限された共有フォルダ
制限された共有フォルダは、通常の共有フォルダと比較して、かなり制限のかけられた機能となっています。 そのため、個人情報などの機密性の高いデータを扱う場合に使用すると効果的だと言えます。 共有フォルダと制限された共有フォルダの違いは以下の4点です。
- 既存のアセットをフォルダに追加することができない
- フォルダ内にあるアセットを使用して作成したアセットをフォルダ外に作成することができない
- フォルダ外にあるアセットを使用して作成したアセットをフォルダ内に作成することができない
- 制限された共有フォルダを作成するにはCLIを使用する必要がある
制限された共有フォルダの作成を作成してみる
制限された共有フォルダはCLIでのみ作成することができます。 制限された共有フォルダを作成する際には、「FolderType」に「RESTRICTED」を指定する必要があります。 制限された共有フォルダが正常に作成されると、フォルダ名に鍵マークがついていることが確認できます。
名前空間
名前空間を使用することで、論理的に分離された環境でユーザーやダッシュボードを作成することができます。 名前空間を分離することで環境自体が分離されるため、よりセキュアなアセット管理が可能になります。 例えば、人事部という名前空間で作成されたユーザーは、営業部という名前空間にあるアセットや総務部という名前空間にあるアセットにはアクセスすることはできません。
行レベルのセキュリティ
ケースによっては、1つのデータセットに対してユーザーごとに閲覧できるデータを制限したい場合もあると思います。 そういった場合に有効なのが、行レベルのセキュリティです。 行レベルのセキュリティは、ユーザーやグループに対して、データ内における行レベルでのアクセス制御をすることができます。 以下の図だと、sales2-deptというグループはDepartmentIdがsales2となっているデータのみにアクセスすることができます。 行レベルのセキュリティが有効になっているかは、データセットの行レベルのセキュリティの部分から確認することができます。
列レベルのセキュリティ
QuickSightは、行レベルだけでなく列レベルでのアクセス制御もできます。 以下の図を例にすると、DepartmentIdがsales1とsales2はNameというカラムとDepartmentIdというカラムにのみアクセスを制限することができます。 列レベルのセキュリティが設定されているかどうかは、行レベルのセキュリティと同じように、データセットの列レベルのセキュリティという項目から確認することができます。
おわりに
QuickSightは、セキュアなアクセス管理を通じてデータの安全性を確保しながら組織内の情報共有を行えるため、ビジネスインテリジェンスの活用において重要なAWSサービスだと言えます。また、QuickSightはセキュアなデータ管理ができる一方で、運用負荷の側面を考慮したデータ管理も大切です。共有フォルダの機能や各種アクセスコントロールの機能を使って効率の良いセキュリティ管理方法を考えていきましょう。
