SBクラウド株式会社logo

MaxCompute連載4:MaxComputeのセキュリティについて

Hi, データエンジニアの大原です。

Alibaba Cloudのデータ処理プラットフォーム「MaxCompute 」についての連載記事の4回目です。

今回はMaxComputeのセキュリティについて説明します。

前回の記事はこちらをご覧ください。 www.sbcloud.co.jp

f:id:sbc_ohara:20210104091159p:plain

前書き

MaxComputeの概要をこのblogにて記載しました。

MaxCompute (旧プロダクト名 ODPS) は、大規模データウェアハウジングのためのフルマネージドかつマルチテナント形式のデータ処理プラットフォームです。さまざまなデータインポートソリューションと分散計算モデルにより、大規模データの効率的な照会、運用コストの削減、データセキュリティを実現します。

f:id:sbc_ohara:20210104133726p:plain

少し前になりますが、MaxComputeについての資料をSlideShareへアップロードしていますので、こちらも参考になればと思います。

www.slideshare.net

今回はAlibaba Cloud MaxComputeおよびDataWorksのセキュリティの考え方、設定方法についてを説明します。

MaxComputeのセキュリティ

MaxComputeは金融機関、通信業界、行政機関独自の厳しいセキュリティ要件をクリアできるほどセキュリティ機能が充実しています。
前回の記事:DataWorksにおける基本モードと標準モード、開発環境と本番環境についてにてMaxComputeとDataWorksはそれぞれ異なる権限を持ったロールがそれぞれのタスク処理をすることを説明しました。今回はこの部分について深掘説明します。

www.sbcloud.co.jp

DataWorksとは

Alibaba Cloud DataWorksは、MaxComputeやHologres、E-MapReduceなどAlibaba Cloudのビッグデータプロダクトを管理、処理するIDEサービスです。
例えば、MaxComputeはこのblog通り、「サーバレス型フルマネージドプラットフォーム」となっています。 「サーバレス型フルマネージドプラットフォームをどうやって操作、運用するの?」という回答がDataWorksに当たります。
アリババグループのデータビジネスの99%はDataWorks上で構築されています。何万人ものデータ開発者やアナリストがDataWorksに取り組んでいます。

f:id:sbc_ohara:20210303200642p:plain

その他、詳しいことは前回の記事【MaxCompute連載】MaxComputeをハンドリングするDataWorksについて にて説明しています。

www.sbcloud.co.jp

セキュリティモデルとアクセス構成

MaxComputeとDataWorksセキュリティモデルとアクセス構成

以前の記事にて、MaxComputeのセキュリティモデルを紹介しました。
MaxComputeでデータをアクセスするためには、このような流れで一つずつチェックされます。これが大前提となります。

STEP1:ユーザー認証・・・Alibaba CloudアカウントとRAMユーザごとに認証・制限
STEP2:IP ホワイトリスト・・・プロジェクトレベルでの保護を提供
STEP3:プロジェクトステータスチェック・・・プロジェクトステータスをチェック
STEP4:ラベルセキュリティチェック・・・ユーザ・列データレベルで機密情報を制御
STEP5:操作権限・・・ユーザごとにテーブルレベルで操作を制限

f:id:sbc_ohara:20210310153057p:plain

一方、DataWorks側でもMaxComputeとは異なったセキュリティモデルがあります。DataWorksでMaxComputeのようにStep-by-step式ではないですが、以下シナリオがあります。

DataWorksセキュリティモデル - 組織間のデータの隔離

・ ユーザー認証とRAMとの連携がサポートされています。Alibaba CloudアカウントはプライマリーアカウントとしてDataWorksをアクティベーションし、プロジェクトを新規作成できます。プロジェクトのメンバーは該当AlibabaCloudアカウント配下のRAMユーザーのみとなります。
・ 同じプライマリーアカウントで作成したプロジェクトたちが一つの組織を構成します。プロジェクトの間にタスクの依頼が設定できます。違うメインアカウントで作成したプロジェクトのデータ(タスク)が隔離されています。

DataWorksセキュリティモデル - 抽出、変換、およびロード(ETL)プロセス中のデータ開発のセキュリティ問題

DataWorksは開発プロジェクトと本番プロジェクトに分けることでタスクの開発/デバッグと本番の隔離を実現します。メンバーのロールを通じて、どのメンバーがタスクの開発とデバッグを実行できるか、どのメンバーが本番タスクを操作および保守できるかを制御します。

DataWorksセキュリティモデル - MaxComputeセキュリティモデルとの組み合わせ

DataWorksはMaxComputeのプロジェクトスペースが正常に作成されると同時に、DataWorksのロールに対応するMaxComputeのロールも作成し、違うロールに権限を付与します。

MaxComputeとDataWorksの権限関係

百聞は一見にしかず、実際どのような構成かを確認してみましょう。

RAM ユーザーを用意します
f:id:sbc_ohara:20210310163456p:plain

DataWorksにユーザーを追加します

f:id:sbc_ohara:20210310163628p:plain

結果として、Userの権限Policyから権限情報を確認することができました。
MaxComputeとDataWorksはAlibaba Cloudアカウント( Alibaba Cloud RootアカウントまたはRAMアカウント)に基づいて権限を与えます。
RAMアカウントがDataWorksワークスペースに追加されたら、自動的に同じ役割でMaxComputeプロジェクトにも追加されます。

f:id:sbc_ohara:20210310214304p:plain


基本モードのプロジェクト-Alibaba Cloud accountでアクセス

今度はMaxCompute操作ユーザー(visitor identity)をAlibaba Cloud accountで設定した場合の挙動を確認しましょう。

f:id:sbc_ohara:20210310130139p:plain

基本モードのプロジェクト-Alibaba Cloud accountで登録、アクセスしてみます。

f:id:sbc_ohara:20210310202526p:plain

プロジェクトsecurity_basic_a_demoに 「dataworks_demo」というRAMユーザーをメンバー・およびDevelopmentら開発ロールで追加してみたところ、

f:id:sbc_ohara:20210310212422p:plain

Account for Accessing MaxCompute = Alibaba Cloud account のもと、 「dataworks_demo」というRAMユーザーとして、プロジェクトsecurity_basic_a_demoでテーブル読み取り操作をすることができました。
このことから、Alibaba Cloud rootアカウント配下のRAMユーザーは該当のプロジェクトおよびMaxComputeテーブルにアクセスするための権限を持ってることがわかります。
また、RAMを追加していない別プロジェクト(Alibaba Cloud accountで設定)のテーブルにもアクセスすることができます。

f:id:sbc_ohara:20210310221430p:plain


基本モードのプロジェクト-Node Ownerでアクセス

次はMaxCompute操作ユーザー(visitor identity)をNode Ownerで設定した場合の挙動を確認します。

f:id:sbc_ohara:20210310130718p:plain

基本モードのプロジェクト-Node Ownerで登録、アクセスしてみます。

f:id:sbc_ohara:20210310212651p:plain

プロジェクトsecurity_basic_n_demoに 「dataworks_demo」というRAMユーザーをメンバー・およびDevelopmentら開発ロールで追加してみたところ、

f:id:sbc_ohara:20210310212721p:plain

Account for Accessing MaxCompute = Node Ownerのもと、 「dataworks_demo」というRAMユーザーとして、プロジェクトsecurity_basic_n_demoでテーブル読み取り操作するとエラーが発生しました。
このことから、MaxCompute操作ユーザー(visitor identity)をNode Ownerで設定した場合、MaxcomputeタスクをサブミットするのはNode Owner(いわゆる個人アカウント)のみとなるため、「dataworks_demo」というRAMユーザーを登録・開発ロールを追加しただけではテーブルへのアクセスができません。

f:id:sbc_ohara:20210310221359p:plain


標準モードのプロジェクトアクセス

続けて、標準モードでプロジェクトを設定した場合の挙動を確認します。

f:id:sbc_ohara:20210310132520p:plain

標準モードでプロジェクトを作成します。

f:id:sbc_ohara:20210311021357p:plain

プロジェクトsecurity_standard_demo1にメンバーを追加します。

f:id:sbc_ohara:20210311124139p:plain

DataWorksで権限を確認します。

開発環境は個人アカウントでデバッグされます。したがって、ノードタスクはRAMアカウントが追加されていないプロジェクトのテーブルにアクセスできません。下記のようにエラーメッセージが表示されます

f:id:sbc_ohara:20210311124256p:plain

MaxComputeで権限を確認します。
標準のDataWorksプロジェクトにRAMアカウントが追加された後、開発環境のMaxComputeにRAMアカウントを自動的に追加され、関連する権限を付与します。本番環境ではRAMアカウントが追加されるが詳細なACLがありません。
理由としては本番環境では、タスクのリリースでは所有者アカウントによって実行されるため、個人アカウントにはデフォルトでタスクをリリースすることができません。

  • 標準モードの本番環境:
    RAMアカウントはジョブを実行する権限がありません

  • 標準モードの開発環境:
    RAMアカウントはジョブを実行する権限があります
    RAMアカウントは追加されていないプロジェクトのテーブルをアクセスすることができません

f:id:sbc_ohara:20210311124520p:plain

標準モードのまとめ
* AlibabaCloud Accountは、DataWorksプロジェクトのプロジェクトOwnerになれます。
* MaxComputeでは、プロジェクトのOwnerまたは通常ユーザーになることができます。
* DataWorksプロジェクトメンバー管理を介してメンバーを追加する場合、該当のプロジェクトプライマリーアカウントに対応するRAMサブアカウントのみを追加できます。
* MaxComputeは、add userxxx; コマンドを使用して他のクラウドアカウントを追加できます。

f:id:sbc_ohara:20210311132708p:plain


プロジェクトセキュリティ

f:id:sbc_ohara:20210310153057p:plain

プロジェクトのセキュリティ管理で、上記は空港をイメージした説明をしましたが、ここについて深堀説明します。
(いらすとやを使って説明したほうがすぐ理解しやすいかなと思ったのですが、色々あって真面目に説明します、、)

プロジェクト内部セキュリティー管理

プロジェクトとして内部のセキュリティは以下の図のように、5つのプロセスで編成されています。

f:id:sbc_ohara:20210311134019p:plain

これがどのようにセキュリティ管理されているか、ここも百聞は一見にしかず、実際確認してみましょう。

前提条件:
プロジェクトを作成( Prj1_demo)
アカウントを用意(ram_test)
※多要素MFA認証を設定すると、毎回登録の際に設定の携帯電話からの認証コードを使う必要があります。ここでは省略します。

この前提条件を踏まえ、以下手順を実施します
ワークスペース名は「Prj1_demo」です。

f:id:sbc_ohara:20210311134837p:plain

ユーザー管理(多要素MFA認証ー省略)

RAMユーザーを用意します。

f:id:sbc_ohara:20210311135007p:plain

Role管理

RAMページより、カスタマイズrole ram_roleを作成します。そのram_roleをram_test アカウントに割り当てます。

f:id:sbc_ohara:20210311135450p:plain

ACL認証

カスタマイズrole role_testに権限を与えてみます。ram_test アカウントでrole_testの権限を検証します。
ram_test アカウント(= ram_role権限を持ってるユーザー)に、テーブル作成のためのCreateInstanceとCreateTableの権限をアタッチします。

f:id:sbc_ohara:20210311135904p:plain

その結果、ram_test アカウント(= ram_role権限を持ってるユーザー)は無事テーブルを作成することができます。

f:id:sbc_ohara:20210311140102p:plain

Policy認証

Policy認証はRoleのみが対象となる、ユーザーへの権限付与ができません。
確認として、今度はPolicy認証を確認するために、drop_testテーブルを作成します。
drop_testテーブル作成直後はDataWorks DataMapで確認することができます。ユーザーは何も権限を付与していないため、このdrop_testテーブルを削除することもできます。

f:id:sbc_ohara:20210311161823p:plain

これに対し、Policy認証を設定します。ProjectOwnerアカウントでram_roleにDropテーブルの権限をPolicyで拒否するか確認します。

Policyとなるjsonファイルの中身は以下の通りです。

{
    "Version": "1",
    "Statement":
    [{
        "Effect":"Deny",
        "Action":"odps:Drop",
        "Resource":"acs:odps:*:projects/prj1_demo_dev/tables/*"
    }]
}

設定し、ram_test ユーザーでPolicyが効くことを検証したところ、、、Policyが効いてエラーが発生したことがわかります。
このように、Policy、ACL、Role、ユーザー別できめ細かいレベルで管理することができます。

f:id:sbc_ohara:20210311162958p:plain

Labelアクセス管理

Labelアクセスはテーブルデータに機密情報などが含まれている場合に適用し、ユーザーごとにセキュリティレベルを付与、閲覧権限をコントロールします。
Labelことセキュリティレベルは全部で4段階となっています。
LABEL 0:無効状態、Unclassified、どのテーブルでも閲覧可能状態(defaultはLABEL 0です)
LABEL 1:秘密、Confidential、テーブルのデータのプレビューを表示することができます。
LABEL 2:機密、Sensitive
LABEL 3:高機密、Highly Sensitive

www.alibabacloud.com

例えば、ram_testユーザーは、デフォルトとなるLABEL 0だとTableデータプレビューができます。この状態でLABEL 1を設定します。
f:id:sbc_ohara:20210311164902p:plain

まずはLabelを有効にします。

show SecurityConfiguration;
Set LabelSecurity=true;

f:id:sbc_ohara:20210311165332p:plain

続いて、ram_testユーザーをLABEL 1 に設定します。

SET LABEL 1 TO USER ram$5445574761551201:239996701173677377;

f:id:sbc_ohara:20210311165521p:plain

テーブルのLabelレベルを1に設定します。

SET LABEL 1 TO TABLE org_log_all_0; 

f:id:sbc_ohara:20210311165547p:plain

これで、org_log_all_0テーブルはLABEL1 以上の権限を持つユーザーでないと閲覧も操作もできない状態となります。

今度はorg_log_all_0テーブルのIP列とUID列だけ、LABELを2にします。

SET LABEL 2 TO TABLE org_log_all_0(ip, uid); 

そのあと、LABEL 1のram_testユーザーがselect * from org_log_all_0 where dt='20200926' limit 10; でテーブルデータを取得してみます。

f:id:sbc_ohara:20210311193352p:plain

結果、↑上記画像通りレコード取得が出来ませんでした。
今度はLABEL2 以外の列(LABEL1のみ)を指定して、テーブルデータを取得してみます。

select 
    time,
    region,
    bytes,
    status,
    method,
    url,
    protocol,
    referer,
    device,
    identity
 from org_log_all_0 
 where dt='20200926' 
 limit 10;

f:id:sbc_ohara:20210311193632p:plain

これは無事取得できました。
今度はLABEL2 のみでの列でデータを取得します。

select 
    ip,
    uid
 from org_log_all_0 
 where dt='20200926' 
 limit 10;

f:id:sbc_ohara:20210311193930p:plain

結果として、権限がないエラーが返ってきました。 またDataMapでも、鍵として非表示されています。

f:id:sbc_ohara:20210311194031p:plain


最後に

MaxComputeのセキュリティについてを説明しました。DataWorksからこのようにきめ細かいレベルでのセキュリティ設定ができます。
MaxComputeのセキュリティはここで説明したものの他に「プロジェクトを跨ぐセキュリティ管理」「アクセス許可リストや設定」「RAMロールのカスタマイズ」など、様々なニーズに応じたセキュリティ設定を行うことができます。
また、これはMaxComputeを対象としたセキュリティ設定ですが、DataWorksからE-MapReduceへのセキュリティ設定はまた別の設定(例えばYARNリソースの制限、クラスターのオートスケール設定、etc)がありますので、こちらもドキュメントを参考にいただければ幸いです。
セキュリティが厳しい要件でも、このようにセキュリティを厳重かつ柔軟に対応できると思いますので、ご参考にいただければ幸いです。

最後までお読みいただきありがとうございました。

参考:

www.alibabacloud.com

www.alibabacloud.com

www.alibabacloud.com

MaxCompute連載シリーズ

www.sbcloud.co.jp www.sbcloud.co.jp www.sbcloud.co.jp www.sbcloud.co.jp www.sbcloud.co.jp