Amazon RedshiftでのRBACについて①

# はじめに
株式会社ジール所属の@hiroaki_yoshidaです。
普段はAWSやPythonを使った開発を行っています。
開発に携わるにあたり、現場で学んだ事をアウトプットしていこうと思います。

今回の記事はAmazon Redshift（以下 Redshift）の権限管理についてです。
わたしは元々SnowFlakeでの権限管理は経験があるのですが、SnowFlakeにはロールという概念があり、今回紹介するRBACとはそのロールと同様な事ができるようになったという紹介になります。

[検証記事はこちらから](https://qiita.com/hiroaki_yoshida/items/bb1c294b6a57dee9e72f)

***
# RedshiftのRBAC実装についてのアナウンス
AWSの公式ページからは以下の様に発表されています。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2166184/9993756f-3970-cc5b-eae1-aaaac2885b69.png" width=50%>


引用元：https://aws.amazon.com/jp/about-aws/whats-new/2022/04/amazon-redshift-role-based-access-control/
***
# 今までの権限管理の方法
今までRedshiftで権限を管理する際は、下記の2通りしかありませんでした。
-  ユーザーへ直接権限を付与
-  ユーザーグループへ権限を付与
-  【NEW】ロールへの権限付与

ユーザーグループはグループに権限を与え、そこにユーザーを所属させることでグループ単位で権限を管理できるというものです。
今回紹介するRBACは新たに追加された権限の管理方法です。

***
# RBACとは

Roll Base Access Controlの頭文字を取ったものになります。
名前の通り、ロールベースアクセス制御になります。
ロールベースアクセス制御では以下のような特徴があります。
1. ロール毎に権限を管理できる
2. ロールを継承できる

それぞれ詳しく見ていきましょう

***
# 1.ロール毎に権限を管理できる
ロールに対して権限を割り振り、ユーザーに対してそのロールを付与することでユーザーに権限を与えることができます。
例として、ユーザー3は特に権限を与えていない為スキーマAにはアクセスできませんが、ユーザー3に対してロールAを付与することでユーザー3がスキーマAにアクセスする事ができるようになります。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2166184/1e35f424-3242-b7a9-72d1-6128814d46dd.png" width=45%>
***

# 2.ロールを継承できる
上位のロールが下位のロールから権限を継承することができます。
例としてスキーマA・Bへのアクセス権を与えらえれたロールA・Bを継承したロールCを用意します。
ロールCは特に権限を与えていませんが、ロールA・Bを継承した為、スキーマA・Bの両方へアクセスする事が可能です。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2166184/e6b8a74c-9d5c-5bf0-e732-7987d975662f.png" width=50%>


***

# ユーザーグループと比較した場合のRBACのメリット

メリットとしては下記が挙げられます

- 記述するSQLが少なくなる
- 権限管理が容易になる

例を用いて考えてみたいと思います。

***
人事部門だけがスキーマを持っており、スキーマを参照できていましたが、今回新たに営業部門のスキーマを作成した為、データを参照できる営業部ロールを新しく作成しました。
それぞれのスキーマはその部門と管理者のロールでしか参照できません。
今回新たに連携されたスキーマは、管理者ロールへ権限を付与する必要があります。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2166184/abd32b28-b322-b2a4-567c-eb2fa647d5be.png" width=50%>

***
### ★ __ユーザーグループ__ で権限管理している場合

管理者のユーザーグループへの権限付与の際に実行するクエリは下記になります。


```SQL

GRANT USAGE ON SCHEMA schema_b TO GROUP group_c;
GRANT SELECT ON ALL TABLES IN SCHEMA schema_b TO GROUP group_c;

```
※ __group_cというのがスキーマ管理者のユーザーグループになります。__ 

<br><br>

### ★ __ロール__ で権限管理している場合

スキーマ管理者のロールへの権限付与の際に実行するクエリは下記になります。


```SQL

GRANT ROLE role_b TO ROLE role_c;

```
※ __role_cというのがスキーマ管理者のロールになります。__ 

***

また、管理が容易については、下記のSQLを実行すると、ロールがどのロールへ継承したのか、されたのかが確認できます。

```SQL

SELECT * FROM svv_role_grants

```

この結果から権限構成を簡単に把握することができます。

***


今回のケースだとあまり差はないのですが、__ロール__ の方がシンプルにかけていますよね。
なんでもそうですが、記述する量が多いと管理が大変で、ミスも多くなります。

また、 __ユーザーグループ__ は各グループが独立しており、権限構成を把握するのが難しいです。
その為、どのグループが一番権限を持っているのかが把握しにくいです。

その点 __ロール__ については継承という概念がある為、上下関係があり分かりやすいです。
まとめると下記の様になります。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2166184/59d75d36-4f31-78fc-7fa0-28e81eae95e2.png" width=70%>



***
# まとめ
この記事ではRedshiftのRBACについて説明しました。
従来の権限管理の方法よりも簡単でわかりやすくなっている事がポイントかと思います。

権限管理でのミスは重大なインシデントに繋がるので、できるだけ簡単にわかりやすくしておきたいですね。

次回は実際にRBACの検証をおこなったので、そちらの内容を共有したいと思います。

>株式会社ジールでは、「ITリテラシーがない」「初期費用がかけられない」「親切・丁寧な支援がほしい」「ノーコード・ローコードがよい」「運用・保守の手間をかけられない」などのお客様の声を受けて、オールインワン型データ活用プラットフォーム「ZEUSCloud」を月額利用料にてご提供しております。
ご興味がある方は是非下記のリンクをご覧ください：

https://www.zdh.co.jp/products-services/cloud-data/zeuscloud/?utm_source=qiita&utm_medium=referral&utm_campaign=qiita_zeuscloud_content-area