この文章は Salesforce 機械翻訳システムを使用して翻訳されました。詳細はこちらをご参照ください。

Newer Version Available

This content describes an older version of this product. View Latest

PolicyCondition インターフェース

トランザクションセキュリティポリシーに基づいて、特定のイベントの発生時に実行するアクションを指定するクラスを実装できるようにする Apex インターフェースです。

名前空間

使用方法

evaluate メソッドは、トランザクションセキュリティポリシーで監視されているイベントが発生するとコールされます。通常の実装では、最初にイベントから関心のある項目を選択します。その項目をテストして、監視されている条件を満たすどうか確認します。条件を満たす場合、メソッドは true を返します。

たとえば、同じユーザが複数回ログインしていないかチェックするトランザクションセキュリティポリシーがあるとします。ログインイベントごとに、メソッドは、ログインしているユーザにすでに進行中のログインセッションがあるかどうかをチェックし、ある場合は true を返します。

PolicyCondition メソッド

PolicyCondition のメソッドは次のとおりです。

evaluate(event)

トランザクションセキュリティポリシーに対してイベントを評価します。イベントでポリシーがトリガされる場合、true が返されます。

署名

public Boolean evaluate(TxnSecurity.Event event)

パラメータ

event: 型: TxnSecurity.Event; トランザクションセキュリティポリシーに対して確認するイベント。

戻り値

型: Boolean

ポリシーがトリガされると、True が返されます。たとえば、ユーザをシングルログインセッションに限定するポリシーがあるとします。あるユーザが 2 つ目のログインをしようとすると、ポリシー��アクションによって現在のセッションを終了するよう求められます。また、Salesforce システム管理者にもメール通知が送信されます。evaluate() メソッドは、ログインイベントのみを確認し、ユーザの 2 つ目のログインである場合に True を返します。トランザクションセキュリティシステムはアクションと通知を実行しますが、evaluate() メソッドは実行しません。

PolicyCondition の実装例

ここでは、さまざまなコード例を示して、トランザクションセキュリティのために TxnSecurity.PolicyCondition クラスを実装する方法を紹介します。これらの例では、異なるイベントコンポーネントを使用して多様な条件を識別し確認する方法を示します。

PolicyCondition の例: localhost ログインのブロック

ログインポリシーで IP アドレスを使用する方法。この例では、localhost からログインがあるとトリガされるポリシーを実装します。

以下は、実装のテストクラスです。

PolicyCondition の例: 大量データのエクスポートのブロック

ログインポリシーで大量データの転送をチェックする方法。この例では、API を使用して 2,000 件以上のレコードがダウンロードされたときにトリガされるポリシーを実装します。

システム管理者または API 権限のある他の顧客は、SOAP API、REST API、または Bulk API を使用して、すべての顧客データを一括ダウンロードできます。このセキュリティポリシーは、API ベースのデータのダウンロードを 2,000 レコードに制限し、ポリシーがトリガされた場合にシステム管理者にリアルタイムで通知します。

この例を拡張して、Lexi Loader またはデータローダのパートナークライアント ID を含める特定の条件を追加することもできます。

PolicyCondition の例: 高保証セッション

機密データにアクセスするときに高保証ログインセッションを義務付ける方法。この例では、特定のレポートにアクセスする全員に 2 要素認証の使用を義務付けるポリシーを実装します。

Salesforce の四半期レポートには非公開の機密データを記載できます。さらに、これらのレポートにアクセスするチームに、このデータを参照する前に必ず高保証の 2 要素認証 (2FA) を使用させることができます。このポリシーは 2FA を義務付けますが、チームに 2FA の要件を満たす手段がなければ高保証セッションを提供できません。前提条件として、まず Salesforce 環境に 2FA を設定します。

この例では、特定のレポートとこのレポートにアクセスする特定のロールに 2FA を適用するポリシーの機能が強調表示されています。ここで定義されるレポートは、「Quarterly Report FY 2016 (2016 会計年度の四半期レポート)」という名前のレポートです。ロール階層を使用して CEO の直属部下であるユーザ全員を定義します。これらのユーザは、レポートにアクセスする前に 2FA を使用して高保証セッションを設定する必要があります。

PolicyCondition の例: プラットフォームブラウザの制限

ロジックポリシーで、特定のオペレーティングシステムとブラウザをチェックする方法。このポリシー例は、OS とブラウザの組み合わせが分かっているユーザが、異なる OS 上で別のブラウザを使用してログインしようとするとトリガします。

アクセスを制限するポリシー例を次に示します。多くの組織では、標準ハードウェアを設定し、さまざまなブラウザの特定のバージョンをサポートしています。この標準を使用して、通常と異なるデバイスからログインが発生したときにアクションを行うことにより、影響が大きいユーザのセキュリティリスクを軽減できます。たとえば、自社の CEO が通常はサンフランシスコから Macbook を使用するか、iPhone で Salesforce1 モバイルアプリケーションを使用して Salesforce にログインするとします。別の場所から Chromebook を使用したログインが発生した場合、それは非常に疑わしいと言えます。企業役員が使用するプラットフォームをハッカーが知っているとは限らないため、このポリシーによりセキュリティ侵害の可能性が低減されます。

この例では、顧客の組織は、CEO が OS X と Safari ブラウザを実行する Macbook を使用していることを知っているとします。その他のものを使用して CEO のログイン情報でログインしようとすると、自動的にブロックされます。

PolicyCondition の例: 場所別のアクセスのブロック

特定の地域からのログインアクセスを完全ブロックする方法。次の例では、国ごとにアクセスをブロックするポリシーを実装します。

組織でリモートオフィスを設置したりグローバルプレゼンスを高めたりすることができますが、国際法に従って Salesforce 組織へのアクセスを制限する必要のある場合があります。こうした制限は、特定の国からのアクセスに対して行うこともあれば、例外的なログインアクティビティが生じたときにアラートを取得することもあります。

この例では、北朝鮮からログインしているユーザをブロックするポリシーを作成します。ユーザが北朝鮮にいながら企業 VPN を使用している場合は、VPN ゲートウェイがシンガポールか米国にあるものと考えられます。この VPN ゲートウェイから Salesforce が米国内に所在する会社の IP アドレスを確認するため、ログインに成功することがあります。

郵便番号や市区郡など、他の特定��値へのアクセスを制限することもできます。

PolicyCondition の例: OS 別のアクセスのブロック

特定のオペレーティングシステムを使用しているユーザのアクセスをブロックする方法。この例では、Android OS の旧バージョンを使用しているユーザのアクセスをブロックするポリシーを実装します。

特定のモバイルプラットフォームの脆弱性や、Salesforce にアクセス中にスクリーンショットをキャプチャしてデータを読み取る機能に懸念のある場合があります。デバイスがセキュリティクライアントを実行していない場合、明確に特定された既知の脆弱性があるオペレーティングシステムを使用しているデバイスプラットフォームからのアクセスを制限することができます。この例では、Android 5.0 以前を使用するデバイスをブロックするポリシーを作成します。

PolicyCondition の例: IP 範囲の変更時のアラート

特定の Salesforce システム管理者に、別のシステム管理者が行った変更を通知する方法。この例では、いずれかのシステム管理者が IP アドレスをホワイトリストに追加したときに、セキュリティ管理者に通知するポリシーを実装します。

大規模なシステムには通常、システム全体の権限をもつシステム管理者が数人います。新しいシステム管理者が機能を更新、変更、または削除したために、環境へのリスクが増大する可能性が懸念されることがあります。

この例のポリシーは、システム管理者がログイン IP アドレスをホワイトリストの IP に追加したときにトリガされ、追加��発生した時点で別のシステム管理者に通知します。このポリシーを実装できるようにするには、組織のセキュリティチームのメール (security@company.com など) がある Salesforce に「セキュリティ管理者」ユーザを追加します。この方法により、セキュリティチームの全員に通知できます。

このポリシーに関連付けられているリアルタイムアクションはありませんが、セキュリティチームにメールアラートが送信されます。このポリシーを作成する場合は次のようになります。

PolicyCondition の例: Chatter 投稿率の制限

単一のユーザが一定の時間内に投稿できる数を制限する方法。この例では、人以外 (ボット) による投稿を防ぐために、15 分間に 5 通を超える投稿ができないポリシーを実装します。

多くの顧客は製品サポートやカスタマー向けコミュニティフォーラムをオープンな方法で運用していて、誰でもアクセスできます。そのため、ときには人以外 (ボット) がこれらのフォーラムにアクセスして望ましくないコンテンツを大量に投稿することがあります。

この例では、15 分間の投稿数を 5 件に制限します。このポリシーによって、ボットがカスタマーコミュニティに望ましくない量のコンテンツを送信できないようになります。ボットが数百件もの投稿を行おうとした場合でも、このポリシーによって、最初の 5 件以降の投稿は15 分間のタイムアウトが過ぎるまではできません。

PolicyCondition の例: 望ましくない Chatter テキストのブロック

特定の用語やコンテンツを含む Chatter 投稿をブロックする方法。この例では、果物の名前を含む投稿をブロックするポリシーを実装しますが、どのような単語でも制限できます。

どのようなオープンフォーラムでも、時としてメンバーのオープンダイアログへの参加ややりとりの方法に問題が生じることがあります。こうしたやりとりの結果、望ましくない行動が生じれば、システム管理者が対処する必要がでてきます。この例では、冒涜的な言葉を使用するユーザから別のユーザへの非公開メッセージをブロックするポリシーを設定します (ここでは冒涜的な言葉の代わりに果物の名前を使用しています)。

PolicyCondition の例: Apex API コールアウトの使用

広告やスパムの送信者は、成功しているコミュニティに頻繁にメッセージを投稿して、ユーザがリンクをクリックする可能性を高めようとすることがよくあります。リンクには望ましくないコンテンツが含まれている可能性があります。Salesforce 外のテクノロジを使用して、さまざまなサービスに基づいてコンテンツをスキャンまたはフィルタできます。

次の例では、コミュニティに望ましくないテキストがあり、ポリシーは API コールアウトを実行して、コンテンツが基準に準拠しているかどうかを確認します。この例では、WDYL.com のシンプルな Google 検索 API を使用しています。

PolicyCondition の例: 接続アプリケーションによるアクセスのブロック

API アクセスが設定された接続アプリケーションによる大量データへのアクセスをブロックします。この例では、果物の名前を含む投稿をブロックするポリシーを実装しますが、どのような単語でも制限できます。

時として、共有または取引先のアクセス権設定の定義により、接続アプリケーションにシステム (組織) 全体のデータにアクセスする API 権限が設定されていることがあります。他方、接続アプリケーションのエンドユーザはアクセスが特定のデータセットに制限されています。この矛盾により、API キーを特定し、データベースに直接コマンドライン検索を実行してリードを探し出すことでセキュリティリスクが増大することがあります。次のポリシーは、こうした状況を回避して、会社のリード情報に関するデータの損失を阻止します。

Apex 開発者ガイド