セキュリティ設定

Supersetの認証と認可は、Flask上に構築されたアプリケーション開発フレームワークであるFlask AppBuilder（FAB）によって処理されます。 FABは、認証、ユーザー管理、権限、およびロールを提供します。 セキュリティに関するドキュメントをご覧ください。

提供されるロール

Supersetには、Superset自体によって処理されるロールのセットが付属しています。これらのロールは、Supersetの進化（およびSupersetバージョンの更新）に合わせて最新の状態に保たれると想定できます。

管理者ユーザーにはその権限がありますが、各ロールに関連付けられた権限を変更する（たとえば、権限を削除または追加する）ことはお勧めしません。各ロールに関連付けられた権限は、superset initコマンドを実行すると（多くの場合、Supersetバージョン間で行われます）、元の値に再同期されます。

これらのロールの権限を示す表は、/RESOURCES/STANDARD_ROLES.mdにあります。

管理者

管理者は、他のユーザーに権限を付与または取り消したり、他のユーザーのスライスやダッシュボードを変更したりするなど、すべての権限を持っています。

アルファ

アルファユーザーはすべてのデータソースにアクセスできますが、他のユーザーにアクセス権を付与または取り消すことはできません。また、自分が所有するオブジェクトの変更に限定されます。アルファユーザーはデータソースを追加および変更できます。

ガンマ

ガンマユーザーのアクセスは制限されています。彼らは、別の補完的なロールを通じてアクセス権が付与されたデータソースからのデータのみを使用できます。アクセス権を持つデータソースから作成されたスライスとダッシュボードを表示することのみが可能です。現在、ガンマユーザーはデータソースを変更または追加できません。彼らは主にコンテンツコンシューマーであると想定していますが、スライスとダッシュボードを作成できます。

また、ガンマユーザーがダッシュボードとスライスのリストビューを見ると、アクセス権を持つオブジェクトのみが表示されることに注意してください。

sql_lab

sql_labロールは、SQL Labへのアクセスを許可します。管理者ユーザーはデフォルトですべてのデータベースにアクセスできますが、アルファユーザーとガンマユーザーの両方にデータベースごとにアクセス権を付与する必要があることに注意してください。

パブリック

ログアウトしたユーザーが一部のSuperset機能にアクセスできるようにするには、PUBLIC_ROLE_LIKE設定を使用し、権限をこのロールに渡したい別のロールに割り当てることができます。

たとえば、superset_config.pyファイルでPUBLIC_ROLE_LIKE = "Gamma"を設定することにより、パブリックロールにガンマロールと同じ権限セットを付与します。これは、匿名ユーザーがダッシュボードを表示できるようにする場合に役立ちます。特定のデータセットに対する明示的な許可が引き続き必要です。つまり、パブリックロールを編集し、パブリックデータソースを手動でロールに追加する必要があります。

ガンマロールのデータソースアクセスの管理

ユーザーに特定のデータセットへのみアクセスを提供する方法は次のとおりです。まず、アクセス制限のあるユーザーに[のみ]ガンマロールが割り当てられていることを確認してください。次に、新しいロールを作成します（メニュー -> セキュリティ -> ロールのリスト）し、+記号をクリックします。

この新しいウィンドウでは、この新しいロールに名前を付け、ユーザーに属性を付け、権限ドロップダウンでテーブルを選択できます。 このロールに関連付けたいデータソースを選択するには、ドロップダウンをクリックして、タイプヘッドを使用してテーブル名を検索します。

その後、ガンマロールに割り当てられたユーザーに、拡張したテーブルに関連付けられたオブジェクト（ダッシュボードとスライス）が表示されることを確認できます。

ユーザーとロール管理のためのREST API

Flask-AppBuilderはユーザーCRUD用のREST APIをサポートしていますが、この機能はベータ版であり、Supersetではデフォルトで有効になっていません。この機能を有効にするには、Superset設定で以下を設定します

FAB_ADD_SECURITY_API = True

設定が完了すると、追加の「セキュリティ」エンドポイントのドキュメントがSwaggerに表示され、探索できます。

権限のカスタマイズ

FABによって公開される権限は非常にきめ細かく、高度なカスタマイズが可能です。 FABは、作成される各モデル（can_add、can_delete、can_show、can_editなど）と各ビューに対して、多くの権限を自動的に作成します。さらに、Supersetは、all_datasource_accessなどのよりきめ細かい権限を公開できます。

Supersetが構築されている一連の前提条件があるため、3つの基本ロールを変更することはお勧めしません。ただし、独自のロールを作成し、既存のロールと結合することは可能です。

権限

ロールは権限のセットで構成され、Supersetには多くのカテゴリの権限があります。権限のさまざまなカテゴリは次のとおりです

• モデルとアクション：モデルは、ダッシュボード、スライス、ユーザーなどのエンティティです。各モデルには、can_edit、can_show、can_delete、can_list、can_addなど、固定された権限セットがあります。たとえば、ダッシュボードエンティティのcan_deleteをロールに追加し、このユーザーにそのロールを付与することにより、ユーザーがダッシュボードを削除できるようにすることができます。
• ビュー：ビューは、ExploreビューやSQL Labビューなどの個々のWebページです。ユーザーに付与されると、メニュー項目にそのビューが表示され、そのページを読み込むことができます。
• データソース：データソースごとに権限が作成されます。ユーザーにall_datasource_access権限が付与されていない場合、ユーザーは、自分に付与されているスライスを表示したり、データソースを探索したりすることしかできません。
• データベース：データベースへのアクセス権を付与すると、ユーザーはそのデータベース内のすべてのデータソースにアクセスでき、SQL Labの特定の権限がユーザーに付与されている場合、ユーザーはSQL Labでそのデータベースをクエリできます。

データソースのサブセットへのアクセスの制限

ユーザーにガンマロールと、特定のデータソースへのアクセスを追加する他のロールを付与することをお勧めします。アクセスプロファイルごとに個別のロールを作成することをお勧めします。たとえば、財務チームのユーザーは、一連のデータベースとデータソースにアクセスできる場合があります。これらの権限は単一のロールに統合できます。このプロファイルを持つユーザーは、アクセスできるモデルとビューの基盤としてガンマロール、およびデータオブジェクトへの権限の集合である財務ロールを割り当てる必要があります。

ユーザーには複数のロールを関連付けることができます。たとえば、財務チームの幹部に、ガンマ、財務、および幹部ロールを付与できます。幹部ロールは、幹部のみが利用できる一連のデータソースとダッシュボードへのアクセスを提供できます。ダッシュボードビューでは、ユーザーは、属性が付けられたロールと権限に基づいてアクセスできるもののみを表示できます。

行レベルセキュリティ

行レベルセキュリティフィルター（セキュリティメニューの下）を使用すると、特定のテーブルと一連のロールに割り当てられるフィルターを作成できます。財務チームのメンバーにdepartment = "finance"の行へのみアクセスさせたい場合は、次のことができます。

• その句（department = "finance"）で行レベルセキュリティフィルターを作成します
• 次に、句を財務ロールとそれが適用されるテーブルに割り当てます

任意のテキストを含むことができる句フィールドは、生成されたSQLステートメントのWHERE句に追加されます。そのため、過去30日間のフィルターを作成し、date_field > DATE_SUB(NOW(), INTERVAL 30 DAY)のような句を使用して特定のロールに適用することもできます。また、複数の条件をサポートすることもできます：client_id = 6 AND advertiser="foo"など。

関連するすべての行レベルセキュリティフィルターがまとめて結合されます（内部的には、異なるSQL句はANDステートメントを使用して結合されます）。これは、2つのロールが競合してテーブルのサブセットが空になる状況を作成できることを意味します。

たとえば、ロールに適用されたフィルターclient_id=4とclient_id=5は、そのロールのユーザーがクエリにclient_id=4 AND client_id=5を追加した結果になり、これは決して真になることはありません。

ユーザセッション

Supersetは、ユーザセッション管理にFlaskとFlask-Loginを使用しています。

セッションクッキーは、リクエスト間のセッション情報とユーザの状態を維持するために使用されます。セッションクッキーには個人ユーザ情報は含まれていませんが、サーバー側でユーザセッションを識別する目的を果たします。セッションクッキーはアプリケーションのSECRET_KEYで暗号化されており、クライアント側では読み取ることができません。そのため、SECRET_KEYを秘密にして、安全で一意な複雑なランダム値に設定することが非常に重要です。

FlaskとFlask-Loginは、セッションの動作を制御するための多くの設定オプションを提供しています。

• 関連するFlask設定

SESSION_COOKIE_HTTPONLY: (デフォルト: False): クッキーにHttpOnlyフラグを設定するかどうかを制御します。

SESSION_COOKIE_SECURE: (デフォルト: False) ブラウザは、クッキーが「secure」とマークされている場合、HTTPS経由のリクエストでのみクッキーを送信します。これが有効になるためには、アプリケーションはHTTPS経由で提供される必要があります。

SESSION_COOKIE_SAMESITE: (デフォルト: "Lax") ブラウザがクロスサイトリクエストと共にこのクッキーを送信することを防ぎます。

PERMANENT_SESSION_LIFETIME: (デフォルト: "31 days") 永続セッションの有効期間をdatetime.timedeltaオブジェクトとして指定します。

サーバー側セッションへの切り替え

サーバー側セッションは、セキュリティとパフォーマンスの面でクライアント側セッションよりも優れています。サーバー側セッションを有効にすることで、セッションデータはサーバー側に保存され、クライアントにはセッションIDのみが送信されます。ユーザーがログインすると、サーバー側にセッションが作成され、セッションIDがクッキーに格納されてクライアントに送信されます。クライアントは、各リクエストにセッションIDを送信し、サーバーはそれを使用してセッションデータを取得します。ログアウトすると、セッションはサーバー側で破棄され、セッションクッキーはクライアント側で削除されます。これにより、リプレイ攻撃やセッションハイジャックのリスクが軽減されます。

Supersetは、サーバー側セッションの管理にFlask-Sessionを使用します。この拡張機能を有効にするには、以下を設定する必要があります。

SESSION_SERVER_SIDE = True

Flask-Sessionは、Flask用の複数のバックエンドセッションインターフェースを提供しています。Redisの例を次に示します。

from redis import Redis

SESSION_TYPE = "redis"
SESSION_REDIS = Redis(host="redis", port=6379, db=0)
# sign the session cookie sid
SESSION_USE_SIGNER = True

コンテンツセキュリティポリシー (CSP)

Supersetは、Talisman拡張機能を使用して、コンテンツセキュリティポリシー (CSP)の実装を有効にします。CSPは、クロスサイトスクリプティング (XSS) やデータインジェクション攻撃などの特定の種類の攻撃を検出して軽減するのに役立つ追加のセキュリティ層です。

CSPを使用すると、サーバー管理者は、ブラウザが実行可能スクリプトの有効なソースと見なすべきドメインを指定することにより、XSSが発生する可能性のあるベクトルを削減または排除できます。CSP互換ブラウザは、許可されたドメインから受信したソースファイルにロードされたスクリプトのみを実行し、他のすべてのスクリプト (インラインスクリプトやイベント処理HTML属性を含む) を無視します。

ポリシーは、一連のポリシーディレクティブを使用して記述されます。各ディレクティブは、特定のリソースタイプまたはポリシーエリアのポリシーを記述します。使用可能なディレクティブはこちらで確認できます。

Supersetをデプロイする際には、多くの種類の攻撃を防ぐために、コンテンツセキュリティポリシーを正しく設定することが非常に重要です。Supersetは、CSPをデプロイするためにconfig.pyに2つの変数を用意しています。

• TALISMAN_ENABLEDのデフォルトはTrueです。CSPを無効にするには、これをFalseに設定します。
• TALISMAN_CONFIGは、実際のポリシー定義 ( *以下の例を参照* ) と、Talismanに渡される他の引数を保持します。

本番モードで実行する場合、Supersetは起動時にCSPの存在を確認します。見つからない場合は、セキュリティリスクに関する警告が表示されます。他のソフトウェアを使用してSupersetの外部でCSPポリシーが定義されている環境では、管理者はconfig.pyのCONTENT_SECURITY_POLICY_WARNINGキーを使用してこの警告を無効にすることができます。

CSP要件

• Supersetが動作するためには、style-src unsafe-inline CSPディレクティブが必要です。

  style-src 'self' 'unsafe-inline'

• nonceでマークされたスクリプトのみを読み込んで実行できます。Nonceは、各ページの読み込み時にTalismanによって自動的に生成されるランダムな文字列です。jinjaマクロcsp_nonce()を呼び出すことで、現在のnonce値を取得できます。

  <script nonce="{{ csp_nonce() }}">
  /* my script */
  </script>

• 一部のダッシュボードは、データURIを使用して画像を読み込み、img-srcにdata:が必要です。

  img-src 'self' data:

• MapBoxチャートはワーカーを使用し、Supersetオリジンに加えてMapBoxサーバーに接続する必要があります。

  worker-src 'self' blob:
  connect-src 'self' https://api.mapbox.com https://events.mapbox.com

• 他のCSPディレクティブは、デフォルトで'self'に設定されており、コンテンツをSupersetサーバーと同じオリジンに制限します。

提供されているCSP設定をニーズに合わせて調整するには、コンテンツセキュリティポリシーリファレンスに記載されている手順と例に従ってください。

その他のTalismanセキュリティに関する考慮事項

TALISMAN_ENABLED = Trueを設定すると、Talismanの保護がデフォルトの引数で呼び出されます。そのうちの1つがcontent_security_policyです。これらは、Talismanのドキュメントの *オプション* に記載されています。これらは一般的にセキュリティを向上させますが、管理者はその存在を認識している必要があります。

特に、force_https = True (デフォルトはFalse) のオプションは、ワーカーがhttp://で始まるWEBDRIVER_BASEURL経由でチャートにアクセスするように設定されている場合、Supersetのアラートとレポートを中断させる可能性があります。Supersetのデプロイメントが、ロードバランサーまたはアプリケーションゲートウェイを介してアップストリームでhttpsを強制している限り、このオプションを無効にしておくことは許容されます。そうでない場合は、次のようにforce_httpsを有効にすることをお勧めします。

TALISMAN_CONFIG = {
    "force_https": True,
    "content_security_policy": { ...

セキュリティの脆弱性の報告

Apache Software Foundationは、ソフトウェアプロジェクトにおけるセキュリティ問題の解消に厳格な立場をとっています。Apache Supersetは、その機能と機能に関する問題に非常に敏感で、進んで対応します。

Supersetのセキュリティに懸念がある場合、または脆弱性や潜在的な脅威を発見した場合は、security@apache.orgにメールを送信して、Apache Security Teamに連絡することを躊躇しないでください。メールには、プロジェクト名Supersetと、問題または潜在的な脅威の説明を明記してください。また、問題を再現および複製する方法を推奨することをお勧めします。セキュリティチームとSupersetコミュニティは、調査結果を評価および分析した後、ご連絡いたします。

パブリックドメインで開示する前に、セキュリティメールでセキュリティ問題を報告することに注意してください。ASF Security Teamは、脆弱性と潜在的な脅威の処理方法を説明したページを管理しています。詳細については、Webページをご覧ください。