Apex メタデータ API とセキュリティについて

ここまで確認してきたように、Apex メタデータ API を使用すると、組織の設定変更を自動化できます。ただし、組織の構造を変更するということは、その組織のデータにセキュリティ上の影響が及ぶおそれがあります。不正なアプリケーションが組織を変更したらどうなるでしょうか? 不安にさせるのは辞めておきましょう。それは起こりえません! 信頼は、Salesforce にとって最も重要な価値の 1 つであり、Apex メタデータ API は信頼できるインターフェースとして構築されました。

Apex メタデータ API の 3 つの機能が組織とデータを保護します。

• 作成または変更可能なメタデータの型に対する制限。
• 変更をリリースできるアプリケーションに対する制限。
• メタデータの変更を追跡する詳細な設定変更履歴。

これらの機能により、「信頼せよ、されど検証せよ」を実践できます。最初の 2 つの機能で、Apex メタデータ API を使用するアプリケーションの機能を信頼できるようになります。3 つ目の機能で、アプリケーションの動作を検証できます。これらの機能しくみを見てみましょう。

セキュリティを確保するため、Salesforce は Apex メタデータ API で作成または変更できるメタデータの型を制限しています。Apex メタデータ API の最初のリリースでは、2 つのメタデータ型 (カスタムメタデータ型のページレイアウトとレコード) を使用できます。将来的にサポートするメタデータ型を増やす予定ですが、Apex でメタデータ API 全体を公開することはありません。このように慎重なアプローチでメタデータをサポートしているため、インストール済みパッケージが使用できるのは、予測可能な方法で変更できる、安全なメタデータ型のみです。

Salesforce では、Apex を介した Apex クラス、Visualforce ページ、Lightning コンポーネントの作成も許可されません。ご想像のとおり、管理パッケージが登録者組織でコードを記述できるとしたら、Salesforce がそのパッケージにセキュリティを適用することは難しくなります。さらに、インストール済みアプリケーションが必ず予測可能な方法でメタデータ型の変更を行うように、Salesforce では自動コード生成をサポートしていません。

作成または変更可能なメタデータの型を制限するだけでなく、Salesforce では Apex 経由でメタデータをリリースできるパッケージを制限しています。Apex メタデータ API がリリースを実行できるのは次の 3 つのシナリオのみです。

• 既知の登録 ISV によって提供された認定管理パッケージから。
• 登録者組織が特定の Apex 設定を有効にしている場合に限り、未認定管理パッケージから (後述)。
• 未管理パッケージから (この場合、コードを実行する組織がそのコードを所有している)。

少し気分が落ち着いてきましたか? こうした制限により、リリースは信頼できるエンティティからのみになります。

Salesforce では、未認定管理パッケージ (Salesforce がセキュリティレビューで承認していないもの) にメタデータリリースの実行を許可する Apex 設定を用意しています。これは [Apex 経由で未認定パッケージバージョンからメタデータをリリース] というわかりやすい名前で、[設定] | [Apex 設定] にあります。未認定パッケージの Apex クラスは、この設定が有効でない限り、メタデータ (公開または保護) にアクセスできません。

この設定を有効にすることで、ISV はまだ認定されていない管理パッケージをテストでき、企業は管理パッケージを使用してアプリケーションをテストまたは更新できます。一方、組織でオフになっている限り、確実に未認定パッケージは組織を変更できないため安心できます。

次の表は、この設定がさまざまなパッケージ種別のリリースをどう制御するかを示します。

管理パッケージの動作は設定変更履歴ログで検証できます。Apex メタデータ API を使用するすべてのメタデータ操作はこのログで追跡されます。リリースを実行するコードの名前空間が記録されます。つまり、どの名前空間がいつ変更を行ったかを常に把握できます。設定変更履歴ログは、[設定] | [設定変更履歴の参照] にあります。

Salesforce が次のように Apex メタデータ API を信頼できるインターフェースにしていることを確認できました。

• 変更可能なメタデータの型を制限。
• メタデータにアクセスできるパッケージの種別を制御。

ただし、これらの制約内で動作する管理パッケージは、その名前空間外のメタデータを変更できます。そのため、開発者には、責任を持ってメタデータを変更できるように、他にも知っておくべきことがあります。

管理 Apex は、未管理 Apex と同じ方法で登録者組織のメタデータを操作しますが、次の 2 つの例外があります。

• 設定変更履歴ログには、管理パッケージの名前空間が含まれるため、これらの変更を追跡できます。
• 管理パッケージ内の保護メタデータは、同じ名前空間の Apex コードからアクセスできますが、登録者組織や他の名前空間からは参照できません。

管理パッケージの Apex によって作成されたすべてのメタデータは、登録者の名前空間で作成されています。管理パッケージは、登録者組織の代わりにメタデータを作成すると考えることができます。次の表は、管理パッケージの名前空間、登録者組織、または別の管理パッケージがメタデータにアクセスする方法を示します。

Apex でメタデータを操作するときは、次の点に留意してください。管理パッケージの Apex は次のことができます。

• 登録者が制御する公開メタデータを更新する。メタデータが同じパッケージ、登録者組織、別の管理パッケージのいずれにあっても関係ありません。
• 同じ名前空間内の登録者が制御する保護メタデータを更新する。このように保護メタデータにアクセスできるため、Apex メタデータ API は多くのアプリケーションを保護するための優れたツールとなっています。アプリケーション設定を保護メタデータとして隠しながら、Apex では操作できます。
• 登録者組織の名前空間にある場合にのみ、開発者が制御するメタデータを更新する。たとえば、管理パッケージの Apex がカスタムメタデータ型のレコードを作成し、そのレコードが登録者の名前空間内にあるとします。管理パッケージのコードは、どの項目でも更新できます。

管理パッケージの Apex で、独自のパッケージに含まれるレコードの、開発者が制御する項目を更新することは、両者が同じ名前空間内にあってもできません。このメタデータは、パッケージアップグレードでのみ更新できます。

ここまでついてこられましたか? テストはないので心配いりません。おっと、これは Trailhead でしたね。クイズはあります!

メタデータ API 自体が信頼のレイヤを追加します。Apex メタデータ API のリリースでは常にメタデータ API 権限が考慮されます。エンドユーザがリリースをキューに追加できるようにする Apex を記述できますが、ユーザに適切なメタデータ API 権限がなければそのリリースは失敗します。

対照的に、Apex メタデータ API からの retrieve コールは、ユーザがアプリケーションからアクセス権を付与されていれば機能します。Apex で公開されるメタデータ型が増えるほど、retrieve コールは、describe 要求では参照できない情報への参照アクセス権を提供する便利な方法になる可能性があります。

ISV の開発者は、Apex メタデータ API を使用するとき、いくつかの点に留意する必要があります。

• セキュリティレビューに合格するためには、アプリケーションがメタデータを変更する可能性があることをお客様に知らせる通知を含める必要があります。
• 未認定管理パッケージのテスト時、登録者組織で [Apex 経由で未認定パッケージバージョンからメタデータをリリース] Apex 設定を有効にする必要があります。
• カスタムメタデータ型のページレイアウトとレコードのみがサポートされます。
• 削除はサポートされません。

これで、Apex メタデータ API を使用して、さまざまな種類のメタデータ変更を自動化する方法を理解できました。Apex の機能を使用して、メタデータを更新するスクリプトと設定環境を作成できます。ここで説明したのは、Apex メタデータ API でできることのほんの一部です。これからみなさんが Apex メタデータ API で素晴らしい機能を開発することを期待しています。Trailblazer コミュニティの「Apex Metadata API」 Chatter グループをご覧ください。