アプリ仕様の概要

このトピックでは、プロバイダーが Snowflake Native App を構成して、アプリ仕様を仕様してコンシューマーからのアクセス制御をリクエストする方法について説明します。アプリ仕様により、コンシューマーは以下のアクションのリクエストを確認し、承認または拒否することができます。

  • Snowflakeの外部にある外部エンドポイントへの接続

  • サードパーティサービスによる認証

  • 他のSnowflakeアカウントとのデータ共有

Snowflake Native Apps のアクセス制御のタイプ

Snowflake Native Apps は、コンシューマーのSnowflakeアカウント以外のリソースとやり取りする必要があることがよくあります。これらの相互作用には、外部サービスへの接続、サードパーティプロバイダーとの認証、他のSnowflakeアカウントとのデータ共有などがあります。

外部サービスにアクセスするために、Snowflakeは次のオブジェクトを提供します。

外部アクセス統合:

ユーザー定義関数またはストアドプロシージャ内で外部ネットワークエンドポイントへのセキュアアクセスを許可します。外部アクセス統合は、ネットワークルールを使用して、特定の外部ネットワークロケーションへのアクセスを制限する。

セキュリティの統合:

OAuth などのサードパーティの認証プロバイダーへの安全なアクセスを許可します。セキュリティ統合は、安全な認証とアクセス制御を提供します。

共有とリスト:

アプリがプロバイダーまたはサードパーティのSnowflakeアカウントにデータを共有するようにします。共有には共有されるデータベースオブジェクトが含まれ、リストはアカウントとリージョン間でデータを共有するメカニズムを提供します。

権限の自動付与 を使用する場合、アプリはセットアップスクリプトを実行するときに、これらのオブジェクトを作成するために必要な権限を持っています。ただし、これらのオブジェクトは外部接続やデータ共有を有効にするため、コンシューマーはアプリを構成するときにこれらの操作を承認する必要があります。

アプリ仕様で権限の自動付与を使用すると、次のような利点があります。

  • コンシューマーは、アプリに必要な統合、共有、リストを手動で作成し、参照を使用してそれらへのアクセスを承認する必要はありません。

  • プロバイダーは、インストール中やアップグレード時に、必要な権限やオブジェクトの存在をチェックするコードを記述する必要がありません。

  • コンシューマーは、外部接続とデータ共有リクエストを明確に可視化し、制御できます。

コンシューマー承認にアプリ仕様を使用

アプリ仕様では、アプリに必要なアクセス制御を指定できます。コンシューマーはアプリをインストールした後、アプリ仕様を確認し、必要に応じて各リクエストを承認または拒否します。これには、外部接続、認証統合、データ共有権限のリクエストが含まれます。

アプリ仕様定義

アプリ仕様定義には、アプリが外部接続やデータ共有などの制御された操作を実行するために必要なプロパティが含まれています。これらのプロパティは承認のためにコンシューマーに表示されます。アプリ仕様定義には、外部アクセス統合、セキュリティ統合、リストなどの操作の型ごとに固有のメタデータとプロパティのサブセットが含まれます。

セキュリティ統合のアプリ仕様定義については、セキュリティ統合のアプリ仕様定義 をご参照ください。

外部アクセス統合のアプリ仕様定義については、EAI のアプリ仕様定義 をご参照ください。

リストのアプリ仕様定義については、リストのアプリ仕様の作成 をご参照ください。

アプリ仕様のシーケンス番号

シーケンス番号は、アプリ仕様のバージョン番号に似ています。シーケンス番号は、プロバイダーがアプリ仕様の定義を変更すると自動的に増加されます。アプリ仕様の定義には、構成の詳細やその他の必要な情報が含まれます。定義の一部ではないフィールド description などは、シーケンス番号の更新をトリガーしません。

シーケンス番号により、プロバイダーとコンシューマーはアプリ仕様のさまざまなバージョンを識別できます。たとえば、プロバイダーがアプリ仕様定義に新しい構成の詳細を追加すると、シーケンス番号が増えます。コンシューマーがアプリ仕様を表示すると、シーケンス番号が変わったことを確認でき、更新されたアプリ仕様を確認できます。

アプリ仕様を使用する場合のベストプラクティス

権限の自動付与 により、外部アクセス統合、セキュリティ統合、リストなどのオブジェクトを作成するために必要な権限がアプリに付与されます。ただし、コンシューマーは、外部接続やデータ共有を可能にするアプリ仕様を拒否することを選択できます。アプリを開発するとき、プロバイダーはアプリ仕様が承認されない可能性を考慮する必要があります

次のシナリオを検討してください。

  • たとえば、アプリは外部アクセス統合のために複数のネットワークポートの使用をリクエストするかもしれませんが、コンシューマーは1つだけ許可する場合があります。アプリには、ネットワークポートが利用できない場合に発生するエラーを処理するロジックが含まれている必要があります。

  • データ共有のリクエストは、一部のターゲットアカウントでは拒否または部分的にのみ承認される場合がありますが、他のアカウントでは承認されません。アプリはこうしたケースを適切に処理する必要があります。

  • 認証の統合は拒否される可能性があり、アプリに代替方法を使用する必要があります。

ベストプラクティスとして、常に適切なエラー処理を含め、どの機能が動作するために承認された仕様を必要とするかについて、明確なフィードバックをコンシューマーに提供します。

アプリ仕様でのコールバック関数の使用

状況によっては、コンシューマーがアプリの仕様を承認または却下したかをアプリが知る必要がある場合があります。例:

  • アプリは、API 呼び出しを行う前に、外部アクセス仕様が承認されるまで待機する必要がある場合があります。

  • データ入力は、リスト仕様が承認された後にのみ開始する必要がある場合があります。

  • セキュリティ統合の承認後に、OAuth フローを初期化する必要がある場合があります。

この状況に対処するため、 Snowflake Native App Framework は、コンシューマーがアプリ仕様を承認または却下したときに実行されるコールバックストアドプロシージャをプロバイダーが定義できるメカニズムを提供します。

プロバイダーは、次の例に示すように、マニフェストファイルにストアドプロシージャを追加できます。

lifecycle_callbacks:
  specification_action: callbacks.on_spec_update
Copy

この例は、マニフェストファイルに callbacks.on_spec_update という名前のストアドプロシージャを作成する方法を示しています。セットアップスクリプトでは、プロバイダーは次の例に示すようにストアドプロシージャを追加できます。

CREATE OR REPLACE PROCEDURE callbacks.on_spec_update (
  name STRING,
  status STRING,
  payload STRING)
  ...
Copy

この例は、 callbacks.on_spec_update というストアドプロシージャの署名を示しています。このプロシージャの本文には、プロバイダーはアプリ仕様のステータスを確認し、オブジェクトを作成し、必要に応じてアクションを実行するために必要なコードを含みます。