Netskope LogoNetskope Logo
  • セキュリティサービス
  • AIサービス
  • ネットワークサービス
  • 分析サービス
  • 統合
  • getting-started.svg始める
    • サポート
    • コミュニティ
    • Netskope.com
    © 2026 無断転載を禁じます。Netskope 株式会社
    トップページ
    次世代 API データ保護プラットフォーム
    次世代 API データ保護ポリシー ウィザード
    次世代 API データ保護ポリシーの作成

    次世代 API データ保護ポリシーの作成

    この記事では、 Netskopeテナント UI で次世代 API データ保護ポリシーを作成する手順について説明します。 その前に、次世代APIデータ保護の基本的な概念を理解しておきましょう。

    露出ベースと俳優ベースのポリシー

    公開性に基づくポリシーは、データの状態を評価します。例えば、ファイルが一般公開されているか、外部ユーザーがアクセスできるかどうかなどです。アクターベースのポリシーは、特定の活動(例えば、公開共有リンクを作成したユーザーなど)を実行したユーザーの身元を評価します。

    次世代 API データ保護は、露出ベースのポリシーのみをサポートします。 アクターベースのポリシー定義はサポートされていません。アクターベースの強制の場合は、 Inline CASBを使用します。

    以下の制限事項のため、アクターベースのポリシー定義はサポートされていません。

    • Rate limiting. 次世代APIデータ保護は帯域外で動作するため、レート制限の対象となる可能性があります。 このような状況では、アクターベースのポリシーが誤って適用される可能性がある。このリスクはInline CASBには存在しません。

    • Race conditions. SaaSプロバイダーからのイベント通知の受信が遅れると、ポリシーエンジンが不完全なデータを処理する可能性があり、アクターベースのマッチングが信頼できなくなる。

    • Increased policy complexity. Netskopeは、サポートされているすべてのSaaSアプリケーションにおいて一貫したポリシーインターフェースを提供することで、ポリシーの作成と長期的な管理を簡素化します。アクターベースのサポートに関してアプリ固有の例外を導入すると、この一貫性が損なわれ、管理上の負担が大幅に増加します。

    次世代のポリシーを作成する

    次世代 API データ保護ポリシーを作成するには、以下の手順に従ってください。

    お客様のご要望に基づき、以下のオプションからお選びください。

    1. NetskopeテナントUIにログインしてください。

    2. Policies > API Data Protectionへ移動してください。

      API Data Protectionページが読み込まれました。

    3. SAASの下にあるNext Genタブをクリックします。

    4. New Policyをクリックしてください。

      New API Data Protection Policyページが読み込まれました。

    5. Objectの下で、お客様の要件に基づいて、以下のオプションを選択してください。

      • All ApplicationsすべてのSaaSアプリとインスタンスにポリシーを適用します。

        All Applicationsを選択した場合、アプリケーションごとにサポートされるアクションが異なるため、一部のアクションが無効になる場合があります。例えば、 All Applicationsを選択すると、「すべてのアプリケーション」でサポートされているアクションのみが利用可能になります。隔離アクションなど、特定のアクションをサポートしていないアプリケーションが1つでもある場合、これらの条件下ではそのアクションはUI上で無効になります。
        ポリシー定義の詳細な制御については、 Netskope ApplicationsまたはApp Instanceオプションを使用することをお勧めします。
      • Applications選択したSaaSアプリにポリシーを適用してください。このオプションを選択すると、特定のSaaSアプリのすべてのアプリインスタンスがポリシーのスキャン対象に含まれます。

      • App Instance選択したSaaSアプリインスタンスにこのポリシーを適用してください。

        使う ファイル分類 使う ボックスラベルを使おうSelectBoxのセンシティビュアラベルアクションを適用するには、Next Gen API データ保護ポリシーを作成する際に、セン シティブラベル統合 のために同じBoxインスタンス使うを選択しなければなりません。
        Microsoft 365 OneDrive または SharePoint アプリ インスタンスが GCC High か商用版かを識別するために、GCC High アプリ インスタンス名には.usがサフィックスとして付加されます。
      • CCI CategoriesSaaSアプリソリューションの種類に基づいてポリシーを適用します。カテゴリを選択すると、該当するすべてのSaaSアプリとインスタンスがポリシーのスキャン対象に含まれます。SaaSアプリのカテゴリと、それに対応するSaaSアプリは以下のとおりです。

        • クラウドストレージ:Box、Dropbox、Egnyte、Google Drive、Microsoft 365 OneDrive、Citrix ShareFile

        • コラボレーションツール:Atlassian Confluence、Cisco Webex、Google Calendar、Microsoft 365 Teams、Microsoft 365 SharePoint、Microsoft 365 Yammer、Slack Enterprise、Smartsheet、Zoom。

        • 顧客関係管理:Salesforce

        • 開発ツール:Atlassian Jira、GitHub

        • 生成型AI:ChatGPT Enterprise、Microsoft Copilot

        • 人事部:Workday

        • IaaS/PaaS: ServiceNow

        • Webmail: Google Mail, Microsoft Outlook

          ApplicationとCategoriesについては、特定のSaaSアプリやインスタンスをポリシー スキャンの対象から除外することもできます。そのためには、 ObjectドロップダウンリストからApplicationまたはCategoriesオプションを選択し、 Exclusionsドロップダウンリストをクリックして SaaS アプリ/インスタンスを選択します。

      • Content: Specify App Instance ドロップダウンリストをクリックし、SaaSアプリのインスタンスを選択してください。スキャン内容ウィンドウが開きます。All contentまたはSpecific resourcesいずれかを選択してください。Specific resources選択した場合、スキャンするリソースIDを含めるか除外するかを指定します。Saveをクリックしてください。

        Microsoft 365 SharePoint オブジェクトをより詳細にスキャンできます。この機能強化により、サイト名またはサイトIDを指定して、SharePointのファイル、フォルダー、またはサブサイトを含めたり除外したりできるようになりました。Scan Contentの下で、 Specific Resourcesを選択してください。Specify Resources to ScanとSpecify Resources to Excludeの下にある編集ボックスをクリックしてください。ドロップダウンメニューから適切な SharePoint ファイル、フォルダー、またはサブサイトSelect 。
        現在、 Netskope送信電子メールの送信フォルダーのみをスキャンできます。 ウェブメールアプリでは、スキャン対象をAll contentに設定することをお勧めします。
        リソースIDを取得するには、 API-enabled Protection > CASB API (NEXT GEN) > Inventoryに移動してください。Name欄の項目をクリックすると、詳細ページが表示されます。Resource ID値をメモしてください。
        サンプルリソースID:
        GitHubの特定のレポジトリをスキャンする場合は、以下の手順に従ってください。
        1. API-enabled Protection > CASB API (NEXT GEN) > Inventoryへ移動してください。
        2. Content Collections > Repositoryタブをクリックしてください。
        3. NameフィールドからGitHubリポジトリを特定します。クリックしてください。
          詳細ペインが開きます。
        4. Resource IDの値をコピーします。
        5. これはGitHubのリポジトリのリソースIDです。
        6. ポリシーウィザードページContent > Specify App Instance > Specific resourcesに戻り、 Specify Resourcesの下にリソースIDを貼り付けてスキャンします。
        7. Saveをクリックしてください。
      • Add Criteriaこのオプションでは、以下の項目に基づいてポリシーをさらに絞り込むことができます。

        • File Type特定のファイルタイプカテゴリに対してポリシーを適用します。ファイル形式のカテゴリ例としては、音声、画像、ワープロ、プレゼンテーション、ビデオなどがあります。

          • ファイル タイプ オプションは、Generative AI、HR、電子メール、およびクラウド ストレージ アプリでのみ使用できます。
          • ファイルタイプの条件は、ファイルに対してのみ照合されます。ファイル以外のリソースは、この基準を無視します。
        • Resource Type特定のリソースカテゴリに対してポリシーを適用します。リソース タイプ カテゴリの例としては、添付ファイル、電子メール メッセージ本文、チャット メッセージ本文などがあります。 選択したSaaSアプリに基づいて、適切なリソースタイプを選択してください。

          • File/AttachmentAtlassian Jira、Gmail、Googleカレンダー、Microsoft 365 Outlookなどのアプリに添付されたファイル。Gmail、Googleカレンダー、Microsoft 365 Outlookなどのアプリには、このリソースタイプSelect 。

          • Email Message Body:電子メールの件名と本文。 Gmail などの電子メール アプリの場合は、このリソース タイプSelect 。

          • Chat Message Bodyチャットメッセージの内容。チャットメッセンジャーアプリには、このリソースタイプSelect 。

          • CommentAtlassian ConfluenceのページまたはJiraチケットに残されたコメント。Atlassian ConfluenceおよびJiraアプリには、このリソースタイプSelect 。

          • PageAtlassian Confluenceで作成、編集、または削除されたページ。Confluenceアプリには、このリソースタイプSelect 。

          • Source Code Commitこれは、GitHubのような開発ツールでソースコードのコミットを監視したい場合に適用されます。

          • Title/Descriptionこれは、Google カレンダーの招待状のタイトルとデスクトップリプションを監視するために、Google カレンダーに適用されます。

          • Ticketこれは、Jiraチケットを監視するためのAtlassian Jiraアプリに適用されます。

          • AI Responseこれは、生成型AIアプリからの応答を監視するために、生成型AIアプリに適用できます。

          • User Promptこれは、エンドユーザーが入力したプロンプトを監視する生成型AIアプリに適用されます。

          • RepositoryこれはGitHubに適用され、リポジトリが公開されたかどうかを監視します。

        • Scan Content Typeストレージ、チケット販売、メッセージングなど、特定のアプリコンテンツタイプのカテゴリにこのポリシーを適用します。

          • StorageAI管理フォルダー、個人用ドライブ、チームドライブ

            AI管理フォルダーを選択した場合は、Microsoft 365 OneDriveインスタンスへのアクセス権を再度付与する必要があります。
          • Generative AI: データ、メモリの微調整

            – これらのオプションは、ChatGPT Enterprise アプリのみに適用されます。
            – データ アップロードを微調整するために、次世代 API データ保護は、DLP スキャンで最大 128 MB のファイルをサポートします。
          • Ticketingカスタムオブジェクト、デフォルトオブジェクト

          • Messagingダイレクトメッセージ、プライベートチャンネル、パブリックチャンネル

          • Calendarプライマリカレンダー、チームカレンダー

          詳細については、 「スキャンコンテンツタイプ」をご覧ください。

        • Activity Type: 特定のユーザーアクティビティタイプのカテゴリにこのポリシーを適用します。

          • ボックス:編集、共有、共有解除、アップロード、名前変更、移動、コピー、復元、ロック、ロック解除、表示、ダウンロード。

          • GitHub: ユーザーがリポジトリに追加され、組織にも追加されました。

        • Google Label Badge: このオプションは、 Applicationsで Google Drive を選択した場合にのみ有効になります。Badge Value(s)の下に、Google バッジの値を入力してください。複数の値は新しい行で区切ります。 バッジの値を確認するには、Google ドライブの管理者アカウントにログインし、 Security > Access and data control > Label managerに移動してください。この機能により、 Netskope Google Drive のバッジ値を読み、 アクションを適用できます。 例えば、文書が機密情報とみなされるバッジ値に一致した場合、警告措置が講じられる可能性があります。現在、アラートポリシーアクションのみを適用できます。

          – 使う Google ブランドバッジを取得する前に、 ここに記載された前提条件を満たしていることを確認してください。
          – Netskope統合を機能させるためには、顧客はすべての必要なバッジフィールドを含む a single label を定義する必要があります。追加の標準ラベルは貼付しないでください。
        • Owner: 所有者とは、ファイル、メールボックス、またはチャット履歴を所有するユーザーのことです。Ownerの下には複数のオプションがあります。何も選択しない場合、デフォルトで全てのユーザーが選択されます。

          Ownerドロップダウンはデフォルトでは無効になっています。有効にするには、以下のリストからアプリを選択してください。

          How ownership is determined?

          応用所有者の定義
          アトラシアン・コンフルエンス– ページ: pageまたはcontent creator 。
          – コメント: コメントを投稿したユーザー。
          – ファイル: File creatorまたはアップローダー。
          アトラシアンJira– チケット: チケット所有者はassigneeです。
          – コメント: コメントの所有者はparent ticket’s assigneeです。
          – ファイル添付: ファイルの所有者はparent ticket’s assigneeです。

          Known Issue
          Jira Cloud では、ユーザーはプライバシー設定を構成して、API レスポンスから自分のアドレスを非表示にすることができます。 この設定がチケットの担当者(所有者)に対して有効になっている場合、Jira API はemailAddressフィールドにnull値を返します。

          Impact
          所有者の電子メール アドレスが利用できない場合:
          – Owner domain or email-based policies do not match
          「所有者のドメインは @company.com です」などのポリシー 所有者の電子メールが利用できないため、評価できません。
          – Owner user profile or domain profile policies do not match
          ドメインベースの分類は、所有者の電子メール アドレスがなければ決定できません。
          – Owner is treated as external for exposure evaluation
          ドメイン情報がない場合、所有者は外部として分類されます。外部暴露基準
          含むポリシーのみ
          トリガーされます。これはJiraのプラットフォーム上の制限であり、所有者属性機能固有のものではありません。既存の暴露および協力者ベースの 評価にも同様の挙動が適用されます。
          BoxFile またはfolder owner .
          注:このボックスは、指定所有者を1名のみ設定できます。
          Cisco Webexファイル: File creatorまたはアップローダー。
          – メッセージ:メッセージの送信者。
          DropboxFolder owner ファイルの所有者です。
          チームフォルダ内のファイルはサポートされていません。
          Egnyteプライベートフォルダ:プライベートフォルダの所有者はファイルの所有者です。
          共有フォルダ:サポートされていません。
          電子メール アプリ (Gmail、Microsoft 365 Outlook)次世代APIデータ保護には「所有者」という概念があり、これは「メールボックスの所有者」を意味します。 現在、 Netskopeスキャン用に送信電子メールのみをサポートしています。 この場合、所有者は常にsenderになります。 所有者の定義を考慮しながらポリシー フィルターの動作を維持するために、 Netskope送信済みフォルダー内の電子メールのスキャンのみを制限します。
          GitHubコードコミット:ソースコードをリポジトリにコミットするユーザー(作者ではない)。
          Googleカレンダーカレンダー/イベントの所有者。
          イベントに関しては、所有権は譲渡可能です。
          Googleドライブマイドライブファイル:所有権が移転されたケースを含むfile creator 。
          共有ドライブのファイルはサポートされていません。
          Microsoft 365 OneDrivedrive ownerは、ドライブ内で誰がファイルを作成したかに関わらず、ファイルの所有者です。
          例えば、ユーザーXがユーザーYのドライブにファイルを作成した場合、そのファイルの所有者はユーザーYになります。
          Microsoft 365 SharePointfile creatorはファイルの所有者として扱われます。
          Microsoft 365 Teams– ファイル: 対応する SharePoint サイト上のfile creator 。
          これは、最後の修飾子または送信者を添付ファイルの所有者として扱う従来のAPIデータ保護とは異なります。
          – メッセージ: Message sender 。
          マイクロソフト コパイロットMessage sender.
          プロンプトを作成したユーザー。
          Salesforce– ファイル: File creatorまたはuploader 。
          – メッセージ、ページ、コメントではサポートされていません。
          Slack Enterpriseファイル: File creatorまたはアップローダー。
          – メッセージ: Message sender 。
          Smartsheet– ファイル: File creator .
          – コメント: コメントを投稿したユーザー。
          ワークデイFile creator またはアップローダー。
          ズームファイル: File creatorまたはアップローダー。
          – メッセージ: Message sender 。

          オーナー向けオプション:

          • Userウェブメールアプリにおけるメールボックス所有者の総数を表示します。1人または複数のユーザーを選択できます。

          • User Group次世代APIデータ保護は、コラボレーションオプションとしてActive Directory(AD)ユーザーグループをサポートします。 この機能強化により、サードパーティのIDベンダーが提供するActive Directoryユーザーグループを含めることができるようになります。リストからユーザーグループSelect 。 ユーザーグループは、ディレクトリインポーターのインストールに含まれています。リストが表示されない場合は、ADユーザーグループをインポートする必要があります。そのためには、 Settings > Tools > Directory Tools > SCIM Integrationにアクセスして SCIM 統合を設定してください。詳細については、 SCIMベースのユーザープロビジョニングを参照してください。

            あるファイルがADグループ内の一部のユーザーのみにアクセス可能な場合、Netskopeはそれをポリシーに一致するものとみなします。
          • User Profileユーザープロファイルで定義されているユーザーのセット。ユーザー プロファイルを使用すると、ポリシー違反のスキャンに含めるか除外するすべてのユーザーの電子メール アドレスを含む CSV ファイルをアップロードできます。 ユーザープロファイルは1つまたは複数選択できます。

          • Domainドメインの一覧を表示します。ドメインは1つまたは複数選択できます。

          • Domain Profileカスタムドメインのリストで構成されるドメインプロファイルを選択できます。ドメインプロファイルを作成するには、 Policies > PROFILES > Domainに移動してください。ドメインプロファイルは1つまたは複数選択できます。

          • Exclusions除外リストを設定することで、 選択した条件のスキャンを除外できます。 ユーザー、ユーザーグループ、ユーザープロファイル、ドメイン、ドメインプロファイルから除外リストを設定できます。

            ファイルをスキャン対象から除外するには、共有されているすべてのドメインを除外リストに含める必要があります。除外リストに含まれていないドメインとファイルが1つでも共有されている場合、そのファイルはスキャンされます。
        • Region: Detect Cross-Region Policyを有効にします。この設定を有効にすると、ポリシーは接続された複数地域間での地域間ファイル漏洩を検出します。

          このポリシーは、インスタンス設定時に明示的にオンボーディングされた複数地域におけるファイル漏洩のみを検出します。
    6. Exposureの下で、次のオプションを選択してください。

      • Exposure: ユーザーとは、保護されたアプリケーションのアカウントに関連付けられた個人またはボットであり、アプリケーション内のコンテンツへのアクセス権(閲覧または書き込み)を持っています。 Exposureの下には複数のオプションがあります。何もオプションを選択しない場合、すべての露出タイプがデフォルトで選択されます。Add Definitionsをクリックすると、 DefinitionとExclusionの 2 つのオプションが表示されます。お客様のご要望に応じて、以下の選択一致オプションに含めたり除外したりできます。

        露出計算は「協調的」なレベルで機能します。例えば、管理者がポリシーに「ユーザー1」を含めた場合、ポリシーに含まれていないユーザーであっても、「ユーザー1」と共有されたファイルはすべてポリシーアラートをトリガーします。
        Salesforceは、ファイルに対してのみ公開フィルターをサポートしています。詳細については、 Salesforce ファイル公開に関するガイダンスをご覧ください。
        アトラシアン管理アカウントの場合、次世代 API データ保護は、電子メール アドレスの公開設定が「誰でも」または「」に設定されている場合にのみ、Atlassian Confluence ユーザーの電子メール アドレスを取得できます。 これは、Atlassianが管理するアカウントのデフォルト設定です。ユーザーの電子メールが非公開の場合、公開オプションは利用できません。 ユーザーの電子メール アドレスが公開されているかどうかを確認するには:
        1. Atlassianアカウントにログインして、 Profile and visibilityページ( https://id.atlassian.com/manage-profile/profile-and-visibility )を表示してください。
        2. [コンタクト] セクションまで下にスクロールし、電子メール アドレスの公開設定がAnyone​または​your company nameに設定されていることを確認します。
        • Userフィールドは空欄のままで構いません(Microsoft Yammer を除く)。そうすると、すべてのユーザーがスキャンされます。
        • Workday のメモ: Netskope 、ドメインの露出を計算するためにユーザーのプライマリ電子メールを使用します。
        • GitHubからの注記:GitHubの公開オプションに関するポリシーが強化されました。詳細については、 GitHub ポリシーの強化をご覧ください。
        • INTERNAL/EXTERNALファイル共有によるリスク要因の一覧は以下のとおりです。

          • 所有者:誰にも共有していません。

          • 内部:内部ドメインで定義された単一のドメインのユーザーとグループ間で共有されるか、アプリインスタンスで内部ユーザーとして定義されます。

          • すべての内部ユーザー:組織内のすべてのユーザーとグループ間で共有されます。

          • 外部:外部のユーザーおよびグループと共有されます。

          • 匿名:一般公開されています。誰でも利用可能。

          • SharePoint/OneDrive:すべての社内ユーザーはEEEU経由でアクセスできます。この脆弱性は、OneDriveおよびSharePointの「外部ユーザーを除く全員」グループを介して共有されたファイルに適用されます。

          詳細については、次世代ファイル共有の脆弱性をご覧ください。

          • Citrix ShareFile および Workday に関する注記: 現在、 Netskope Citrix ShareFile および Workday の露出レベルを計算するために内部ドメイン設定を使用していません。
          • GitHubからの注記:GitHubの公開オプションに関するポリシーが強化されました。詳細については、 GitHub ポリシーの強化をご覧ください。

          • Microsoft Yammer に関する注記: Microsoft Yammer には匿名ユーザーは存在しません。すべてのユーザーは Yammer 組織に属しています。

          ファイル共有によるリスクの例をいくつか挙げます。

          1. 実行したい場合は すべての内部名前付きユーザー (例: michael@abc[.]com、 steve@abc[.]comなど)、 Interna l オプションを選択すると、指定されたユーザーと共有されているすべてのドキュメントが表示されます。

          2. 共有オプション(リンク共有か指定ユーザー共有かなど)に関係なく、すべての内部ユーザーに一致するポリシーを実行する場合は、次のオプションを選択します。

            • Owner

            • Internal

            • すべての内部ユーザー

              これは、上記のいずれかの露出オプションで共有されているすべてのファイルと一致します。

        • User Geoこれは、特定の複数地域から発生したとフラグ付けされたエンティティに一致します。このフィルターを選択すると、複数のユーザーの地理的位置を選択できます。

          この露出フィルターは、Microsoft 365 アプリにのみ適用されます。
        • User Group次世代APIデータ保護は、コラボレーションオプションとしてActive Directory(AD)ユーザーグループをサポートします。 この機能強化により、サードパーティのIDベンダーが提供するActive Directoryユーザーグループを含めることができるようになります。リストからユーザーグループSelect 。 ユーザーグループは、ディレクトリインポーターのインストールに含まれています。リストが表示されない場合は、ADユーザーグループをインポートする必要があります。そのためには、 Settings > Tools > Directory Tools > SCIM Integrationにアクセスして SCIM 統合を設定してください。詳細については、 SCIMベースのユーザープロビジョニングを参照してください。

          あるファイルがADグループ内の一部のユーザーのみにアクセス可能な場合、Netskopeはそれをポリシーに一致するものとみなします。
        • User Profileユーザープロファイルで定義されているユーザーのセット。ユーザー プロファイルを使用すると、ポリシー違反のスキャンに含めるか除外するすべてのユーザーの電子メール アドレスを含む CSV ファイルをアップロードできます。

          • ユーザープロフィールは、ここに掲載される前に追加する必要があります。ユーザープロファイルを含むCSVファイルをダウンロードするには、 Policies > Profiles > Userにアクセスし、 New User Profileをクリックしてください。New User Profileウィザードの手順を完了したら、ここでユーザープロファイルを選択してください。
          • GitHubからの注記:GitHubの公開オプションに関するポリシーが強化されました。詳細については、 GitHub ポリシーの強化をご覧ください。
        • Domainドメインの一覧を表示します。ドメインは1つまたは複数選択できます。

          Smartsheetはドメインベースの公開ポリシーをサポートしていません。
        • Domain Profilesカスタムドメインのリストで構成されるドメインプロファイルを選択できます。ドメインプロファイルを作成するには、 Policies > PROFILES > Domainに移動してください。

          • Citrix ShareFile および Workday に関する注記: 現在、 Netskope Citrix ShareFile および Workday の露出レベルを計算するためのドメイン プロファイル設定をサポートしていません。
          • GitHubからの注記:GitHubの公開オプションに関するポリシーが強化されました。詳細については、 GitHub ポリシーの強化をご覧ください。
        • # Internal Named Usersコンテンツ共有がポリシー違反となるしきい値を設定するには、クリックして内部ユーザーの範囲と数を設定します。More ThanまたはLess ThanラジオボタンSelect 、違反が発生するために検出する必要のある内部協力者の数を入力します。 違反が発生する。

        • Exclusions: ポリシーからスキャンを除外する除外リストを設定できます。ユーザープロファイル、内部ドメインと外部ドメイン、匿名ユーザー、ドメインプロファイルから例外リストを設定できます。

          – 次世代APIデータ保護ポリシーを External または Anonymous 露出スキャンタイプで作成し、除外フィールドに1つ以上のドメインプロファイルを追加すると、Next Generation API データ保護今は自動的にドメインプロファイル除外リストから1 All Internal Domains を選択します。 管理者は、必要に応じていつでも事前に選択されたAll Internal Domainsドメインプロファイルを削除できます。
          この挙動は、組織外で共有されたファイルを検出するために設計された外部・匿名曝露ポリシーの意図した使うを反映しています。 ドメインプロファイルが特定の外部ドメインを除外する際には、暗黙の意図としてスキャン範囲からすべての内部ドメインを除外することも含まれます。 以前は、Next Generation API データ保護では内部ドメインがデフォルトで選択されておらず、意図しないスキャン動作を引き起こすことがありました。
          – GitHubの注記:露出オプションに関するGitHubのポリシー強化があります。詳細はこちら: GitHubポリシー強化
    7. Profile & Actionの下で、以下のオプションを選択してください。

      さまざまなプロファイルとアクションをサポートするアプリの完全なリストについては、 「クラウド アプリごとの次世代 API データ保護機能マトリックス」を参照してください。
      • Profile以下のいずれかのオプションを選択してください。

        • None

        • DLPこのオプションを選択した場合は、リストから定義済みまたはカスタムのDLPプロファイルを1つ以上選択してください。DLPプロファイルを管理するには、 Policies > PROFILES > DLPに移動してください。DLPの管理に関する詳細は「 データ損失防止」をご覧ください。

        • Threat Protectionこのオプションを選択すると、あらかじめ定義されたデフォルトのマルウェアスキャンプロファイルが選択されます。カスタムマルウェアプロファイルは、今後のリリースで導入される予定です。

          次世代APIデータ保護は、悪意のあるファイルを処理する際に、従来のAPIデータ保護と同様の長年にわたる動作を踏襲します。 SaaSアプリケーションがマルウェアを検出してブロックした場合、Netskopeは設定された修復アクションを実行しません。その代わりに、脅威防御エンジンはポリシーに基づく修復措置を適用することなく、顧客に通知するためのアラートを生成します。

          深刻度に基づいた修復措置を、低、中、高の3段階で設定できます。深刻度ごとに、アクションを定義できます。脅威保護ポリシーは、ポリシー一致で実行される重大度ベースのアクションを定義します。 深刻度に応じて隔離措置を選択した場合、UIはオプションのパスワードを入力するよう促します。これは、マルウェアに感染して隔離されたファイルを開くためのパスワードです。パスワード欄は任意入力ですが、Netskopeではこの欄を空欄にしないことを推奨しています。なぜなら、一部の圧縮ソフトウェアは空欄のパスワードをサポートしていないためです。

          – Classic API データ保護における脅威保護の重大度ベースの修復アクションはテナントレベル ( Settings > Threat Protection > API-enabled Protection ) であったことに注意することが重要です。 ただし、次世代 API データ保護では、ポリシー レベルです。 つまり、この機能をポリシーごとに細かく制御できるということです。
          – この機能展開の一環として、次世代 API データ保護はサードパーティのエンドポイント検出および応答 (EDR) をサポートしません。 脅威隔離に対して深刻度に基づいた修復アクションを設定する場合、修復エンドポイントを選択するオプションは表示されません。Policies > Threat Protectionの下では修復プロファイルを構成できません。代替手段として、 Netskope Cloud Exchange利用して同じ操作を実行することもできます。 詳細については、以下を参照してください。
          – Threat Exchange 用 Carbon Black プラグイン
          – Threat Exchange 用 CrowdStrike プラグイン


          • 次世代APIデータ保護は、DLPおよび脅威保護のために最大128MBのファイルをサポートします。 デフォルトのファイルサイズは32MBに設定されています。ただし、この拡張機能を試したい場合は、 Netskopeの営業担当者/サポートに問い合わせて、テナントでこれを有効にしてください。

          • Netskopeは、Atlassian Confluenceのファイル添付ファイル内のマルウェアのみを検出できます。


      • Actionポリシー違反が発生した場合に取るべき措置。

        さまざまなアクションをサポートするアプリの一覧については、 Next Generation API データ保護機能マトリックス(クラウドアプリごとの機能マトリックス)を参照してください。
        • 警告: このアクションを選択してポリシー違反が発生した場合、Netskope はSkope IT > Alertsページに通知を送信します。

          アラートは過去30日間分のみ生成されます。
        • 機密ラベルの適用:この操作は、機密性の高いファイルにデジタル著作権管理(DRM)ラベルを適用します。データ権利管理とは、デジタルコンテンツを分類し、そのアクセスを管理することを目的としたソリューションの一種です。Netskopeは、Box、Google、およびMicrosoft Purview Information Protection(MPIP、旧称Microsoft Information Protect)のラベルをサポートしています。この操作により、DLP(デジタル損失防止)の対象となるファイルに、Box、Google、またはMPIPのラベルを適用できます。この操作を選択したら、DRMベンダー、インスタンス、およびラベルを選択する必要があります。この機能をサポートするアプリの一覧については、 「クラウドアプリごとの次世代APIデータ保護機能マトリックス」を参照してください。

          Box、Google、またはMPIPのセンシティブラベルを適用する前に、まずBox、Google、またはMPIPのインスタンスを設定する必要があります。詳しくはこちら: デジタル著作権管理。
          – Box感度ラベルアクションを適用するには、次世代APIデータ保護ポリシーを作成する際に、同じBoxインスタンス使うを選択して Sensitivity Label Integration を行う必要があります。
          この機能は、高度なDLPソリューションの一部です。これをテナントに許可するには、Netskopeの営業担当者に相談してください。
        • 所有者を特定のユーザーに変更する:この操作により、ファイルの所有者が特定のユーザーに変更されます。このオプションをクリックすると、UIは特定のユーザーのアドレスを入力するように促します。 アドレス

          現在、この機能はGoogleドライブとWorkdayアプリでのみ利用可能です。詳細については、ポリシーアクションの特別な動作を参照してください。
        • 削除: この操作は、違反しているファイル、フォルダ、チャット メッセージなどを削除します。SaaSアプリの細かい違いについては、次世代APIデータ保護機能マトリックス(クラウドアプリごとの機能マトリックス)を参照してください。

          必要に応じてポリシーを修正してください。露出レベルを「すべて」、ポリシーアクションを「削除」に設定すると、ポリシーによってストレージアプリからすべてのコンテンツが削除されます。

          従来の API データ保護とは異なり、削除アクションは DLP プロファイルにバインドする必要がないため、 フォルダーなどのコンテンツコレクションを削除できます。 しかし、SaaSアプリのアップストリームAPI機能により、ポリシーに一致した場合でも、一部の特殊なコンテンツコレクションは削除されない場合があります。

          SaaSアプリ / 削除可能なコンテナFilesFolders個人的な意欲共有ドライブSites
          Googleドライブはいはいいいえはい適用できない
          Microsoft 365 OneDriveはいはいいいえ適用できないいいえ
          Microsoft 365 SharePointはいはい適用できないはいいいえ
        • 隔離:この操作により、影響を受けるファイルが隔離され、削除されます。リストから既存の隔離プロファイルをSelectするか、新しいプロファイルを作成してください。詳細については、 [次世代]隔離プロファイルを作成してください。

          追加参考文献:
          – Microsoft Office 365ファイルタイプ用のQuarantine Tombstone
          – Google Workspace ファイルタイプ用の Quarantine Tombstone
        • 法的保留:この措置により、組織は訴訟が合理的に予測される場合に、関連するあらゆる形態の情報を保存することができます。ファイルがポリシーの基準を満たしている場合、法的目的のためにコピーを保存することを選択できます。リストから既存の法的保留プロファイルSelectか、新しいプロファイルを作成してください。

        • 内部ユーザーへのアクセスを制限する: このアクションは、 Settings > Administration > Internal Domainsで定義されている組織およびドメイン内のユーザーに対してファイルへのアクセスを制限します。

          GitHubに関する特記事項。詳細については、ポリシーアクションの特別な動作を参照してください。
        • 所有者のみにアクセスを制限する:この操作により、ファイルのアクセスは所有者のみに制限されます。

          Googleドライブに関する特記事項。詳細については、ポリシーアクションの特別な動作を参照してください。
        • 所有者のドメインへのアクセスを制限する:現在のドメイン内のユーザーのみにアクセスを制限します。ユーザーの電子メール ドメインがファイル所有者のものと異なる場合は、ファイルのアクセス許可を削除します。 現在のドメインのユーザーのみがアクセスできます。

        • 特定のドメインへのアクセスを制限する:ドメインプロファイルに記載されているドメインのユーザーのみにアクセスを制限します。指定されたドメインプロファイルに一致するユーザーのみがアクセスできます。

        • 特定のドメインと内部ユーザーへのアクセスを制限する: この操作により、前の項目で定義された選択されたドメインと内部ユーザーのみがファイルにアクセスできるようになります。このオプションをクリックすると、UIにドメインプロファイル名の入力を求められます。

          ドメインプロファイルが定義されていない場合は、 Manage Domain Profilesをクリックして新しいドメインプロファイルを作成してください。
        • 特定のユーザーへのアクセスを制限する:ユーザープロファイルに登録されているユーザーのみにアクセスを制限します。指定されたユーザープロファイルに一致するユーザーのみがアクセスできます。

        • 特定のドメインからのアクセス権を取り消す:この操作により、指定されたドメインプロファイルに一致するユーザーのアクセス権が削除されます。このオプションをクリックすると、UIにドメインプロファイル名の入力を求められます。

          • ドメインプロファイルが定義されていない場合は、 Manage Domain Profilesをクリックして新しいドメインプロファイルを作成してください。
          • 詳細については、付録の「ゲスト/外部ユーザーの解析制限」セクションを参照してください。
        • 特定のユーザーからのアクセス権を取り消す:ブロックリストに登録されているユーザープロファイル以外のすべてのユーザーからのアクセス権を取り消します。指定されたユーザープロファイルに一致するユーザーのアクセス権を削除します。

        • 組織全体の共有設定を取り消す:この操作を行うと、組織全体の共有リンクがすべて削除されます。

          直接リンクを持っている人、または文書に追加された人は、引き続きアクセス権を保持します。
        • 公開共有の取り消し:一般公開アクセス/公開リンクを削除します。アクセス権を持つユーザーのみがファイルを開くことができます。

        • ファイルレベルで追加されたユーザーのアクセス権を取り消す:この操作により、ファイルにアクセスできないように、個別にリストされたユーザー(内部ユーザーまたは外部ユーザー)が削除されます。この操作は現在、Microsoft 365 OneDriveおよびSharePointで利用可能です。

          Microsoft 365 OneDriveおよびSharePointに関する特記事項。詳細については、ポリシーアクションの特別な動作を参照してください。
        • SharePoint/OneDrive: EEEU共有の取り消し: OneDriveおよびSharePointで「外部ユーザーを除く全員」(EEEU)グループを介して共有されたファイルの場合、この操作によりEEEUグループへの公開が解除されます。

        • 印刷とダウンロードを無効にする:ユーザーがファイルを印刷したりダウンロードしたりすることを制限します。このポリシーアクションを適用することで、閲覧のみにアクセスを制限することができます。

        • リンクの有効期限を設定する:公開されたリンクは「x」日後に期限切れになります。このオプションを選択すると、リンクの有効期限が切れるまでの日数を指定するよう求めるメッセージが表示されます。

          この機能はBoxストレージアプリでのみ利用可能です。Boxに管理者としてログインし、 Admin Console > Enterprise Settings > Content & Sharing タブに移動してください。下にスクロールしてAuto-Expiration設定を探し、 Allow item owners and editors to modify the expiration dateを有効にしてください。この設定は、この操作を実行するために必要です。
        • 共有を閲覧のみに制限する:ファイルとフォルダから編集権限とコメント権限を削除します。

      • + Notification: ポリシー ウィザードでイベントの電子メールまたはメッセージ通知を定義できます。 これらの通知は、ポリシー違反やアラートなどのイベントによってトリガーされ、管理者および指定されたユーザーグループに重要な活動に関するタイムリーな情報を提供します。追加設定を行うには、 + Notificationをクリックしてください。

        電子メール通知をサポートするアプリのリストについては、 「クラウド アプリごとの次世代 API データ保護機能マトリックス」を参照してください。
        • How often to notify people定期的な間隔(30分、60分、6時間、24時間)またはイベント発生ごとに選択できます。After each eventには追加のオプションがあります。メッセージ通知は、以下の宛先に送信できます。

          以下のオプションは現在、Cisco WebexおよびSlack Enterpriseアプリでのみ利用可能です。
          • 行為ユーザー:ポリシー違反を引き起こすメッセージを送信したり、ファイルをアップロードしたりするユーザー。

          • アプリインスタンスの所有者:Slack Enterpriseインスタンスを設定した組織の所有者。このオプションはSlack Enterprise版のみで利用可能です。

          • グループチャット:Cisco Webexインスタンスの設定後にNetskopeによって作成されたプライベートスペースNetskope-Alertにメッセージを送信します。このオプションはCisco Webexでのみ利用可能です。

          • 選択されたユーザー: 電子メールまたはユーザー プロファイルに基づく特定のユーザー。

        • Send notification to通知は以下に送信できます。

          • Owner: 電子メール、メッセージ、またはファイルの作成者。

            GitHub の電子メール通知を構成する場合、 Ownerフィールドはリポジトリには適用されません。
          • Admin: インスタンスのセットアップの一部として設定された管理者電子メール。

          • Collaborators: 電子メール、メッセージ、またはファイルを共有する全員。

          • Last Acting Userこのオプションは、ポリシー違反が評価された時点で、ファイルの編集、共有、アクセス許可の変更など、ファイルに対して最後に操作を行ったユーザーにアラートを送信します。

            – このオプションは現在、ストレージSaaSアプリでのみサポートされています。
            最後に操作を行ったユーザーまたは変更者は、可能な限り特定します。Microsoft 365 OneDriveのようなSaaSアプリは、APIを介してユーザーデータを送信するのに遅延が生じる場合があるため、通知されるユーザーは、以前に編集されたファイルに基づいて通知を受ける可能性があります。
          • Selected Users: Specified users.

          デフォルトの電子メール テンプレートを使用することも、通知用の新しいテンプレートを作成することもできます。

        • From User: オプションで、通知の送信元となる電子メール アドレスを入力できます。

      • + Set Time Triggerポリシー違反が発生した場合、猶予期間を設けることができます。この猶予期間中は、警告のみの状態となり、ユーザーまたは管理者が問題の解決や例外の申請を行うことができます。違反が設定された期間内に解決されない場合、ポリシーは自動的にフォローアップ措置を実行します。追加設定を行うには、 + Set Time Triggerをクリックしてください。

        この機能は段階的に展開されます。テナントでまだ有効になっていない場合でも、特に操作は必要ありません。まもなく、より多くのテナントで利用可能になります。
        – この設定は、「アラート」以外の操作をサポートするSaaSアプリケーションでのみ利用可能です。さまざまなアクションをサポートするアプリのリストについては、 「クラウドアプリごとの次世代APIデータ保護機能マトリックス」を参照してください。
        1. + 通知: ポリシーが初めて一致したときに通知するように設定できます。

          最初のポリシー一致では、アクションはAlertに制限されます。タイマーが切れる前に発生したそれ以降のマッチについては、記録保持のためにSkope ITアラートが生成されます。

        2. X 日後のフォローアップ アクション: ポリシー アクションが施行されるまでの修復の猶予期間 (1 ~ 90 日) を定義します。

        3. アクション: Object > Applicationsで選択した特定の SaaS アプリのアクション リストから、フォローアップ アクションを定義します。

          Only remove users how match the policy the first timeチェックボックスは、ほとんどのRestrict Accessアクションを選択した場合に表示されます。このオプションは、延期されたポリシー アクションの一環としてユーザーが共有またはアクセスから削除されるタイミングを制御するために使用します。 有効にすると、最初のポリシー一致時に識別されたユーザーのみが追跡され、個々のタイマーが期限切れになると削除されます。この設定に対するその後の変更は、新しく作成されたタイマーにのみ適用され、既存の延期されたアクションは中断や遡及的な影響を受けることなく引き続き実行されることが保証されます。

        4. + フォローアップ通知:前述のとおり、X日経過後もポリシーが依然として適用される場合に通知を設定できます。

        フォローアップアクションと保留中のトリガーの詳細については、 「保留中のトリガーの処理方法」を参照してください。
    8. Policy Nameの下に、ポリシー名を入力してください。そして短いデスクリプション。

    9. Statusの下で、ご要望に応じて以下のオプションを選択してください。

      • 無効:ポリシーを無効のままにしておき、後で有効にします。

      • 有効化:ポリシーを有効にすると、すぐに有効になります。

    10. 右上のSaveをクリックしてからApply Changesをクリックします。

      新しく作成されたポリシーは、ポリシーのホームページに表示されるはずです。

      ポリシーを無効にしたままにしている場合は、必ずポリシーを有効にしてください。ポリシーエントリの右側にあるその他のオプションアイコン( … )をクリックし、 EnableをクリックしてからApply Changesをクリックします。

    次に、 Incidents > DLPの下の DLP インシデントを表示できます。DLPインシデントの詳細については、 「DLPについて」を参照してください。

    保留中のトリガーをどのように処理すればよいですか?

    延期されたポリシー アクションを使用すると、ポリシー違反により保留中のトリガー (後で実行するようにスケジュールされたアクション) が発生する可能性があります。 状況によっては、セキュリティ要件の更新に合わせて、これらの保留中のトリガーを確認、変更、またはリセットする必要がある場合があります。

    このセクションでは、管理者が保留中のトリガーを管理するために利用できるオプションと、各オプションを使用するタイミングについて説明します。 各オプション。

    オプション 1: リセットして最初からやり直す

    次のような場合は、白紙の状態から始めたほうがよいでしょう。

    • あるポリシーによって、多数の誤検出が発生している。

    • ポリシーの仕組みを再設計または大幅に変更したいと考えています。

    What to do?

    • 保留中のトリガーに関連付けられているポリシーを削除します。

    • (オプション)更新された基準またはアクションを含む新しいポリシーを作成し、古いポリシーを削除します。

    What happens?

    • 削除されたポリシーに関連付けられている保留中のトリガーはすべてキャンセルされます。

    • 削除前に警告が表示され、保留中の操作は実行されないことが通知されます。

    • 保留中のトリガーが削除されたことを記録するために、アラートが生成されます。

    • キャンセルされたトリガーについては、エンドユーザーに通知は送信されません。

    このオプションは、過去の決定を消去し、まっさらな状態から執行体制を再構築したい場合に役立ちます。

    オプション2:保留中のすべてのトリガーに新しいアクションを適用する

    保留中のトリガーに対して、元々設定された
    とは異なるアクションを実行させたい場合 (たとえば、隔離からアクセス権の取り消しに変更する場合) は、この操作を行うと良いでしょう。

    What to do?

    • 既存のポリシー内のアクションを変更します。

    What happens?

    • 更新されたアクションは、既存の保留中のすべてのトリガーに適用されることをお知らせします。

    • 保留中のトリガーは、新しく設定されたアクションを消費して実行します。

    • ポリシーアクションが更新されたことを記録するために、アラートが生成されます。

    • 更新されたアクションが実行されると、エンドユーザーに通知されます。

    このオプションは、執行戦略が変更された場合でも、保留中の措置を引き続き進める必要がある場合に、整合性を維持するのに役立ちます。

    オプション3:既存の保留中のトリガーを保持し、今後の動作を変更する

    次のような場合は、この操作を行うと良いでしょう。

    • 既存の保留中のトリガーが、当初の計画どおりに完了することを望んでいる。

    • 新たな違反については、異なる強制アプローチに従う必要があります。

    What to do?

    • 既存のポリシーを無効にします。

    • 更新されたアクションを含む新しいポリシーを作成します。

    What happens?

    • 既存の保留中のトリガーは引き続き実行され、当初設定されたアクションが実行されます。

    • 新しい違反は、新しいポリシーに照らしてのみ評価されます。

    • ポリシーを無効化した場合の影響について通知されます。

    この選択肢は、過去の決定を遡及的に変更することなく、継続性を確保します。

    適切なアプローチを選択する

    あなたの目標推奨オプション
    予定されていたすべてのアクションをキャンセルし、ポリシーを再設計するポリシーを削除する(オプション1)
    すべてのスケジュール済みアクションに新しいアクションを適用するポリシーアクションを変更する(オプション2)
    既存のスケジュールされたアクションは維持しつつ、今後の動作を変更する。ポリシーを無効化して再作成する(オプション3)

    適切なオプションを選択することで、セキュリティとビジネス要件の変化に合わせてポリシーを整合させながら、執行の延期を自信を持って管理できます。

    付録 – SaaSアプリの特殊な動作

    GitHub ポリシーの強化

    当初、GitHubでは、ユーザープロファイル、内部ドメイン、外部ドメイン、匿名ユーザー、ドメインプロファイル、除外設定など、特定のデータ保護ポリシーの公開オプションが利用できませんでした。この制限は、 Netskopeが GitHub からユーザーの電子メール ID を取得できないことが原因でした。 最新のアップデートにより、 Netskope GitHub からユーザーの電子メール ID を取得できるようになり、データ保護を改善する可能性が広がります。 しかし、いくつかの前提条件があります。

    • SAML SSO 設定: この機能を有効にするには、GitHub 組織で SAML シングルサインオン (SSO) を設定する必要があります。

    • NameID としての電子メール: SAML 構成の NameID が電子メール アドレスに設定されていることを確認します。

    • SSOの強制適用:組織内のすべてのメンバーに対してSSOを強制適用することが非常に重要です。

    これらの基準が満たされると、 Netskopeユーザーの電子メール ID を GitHub からシームレスに取得します。 この画期的な機能により、高度なポリシー公開オプションを活用できるようになり、GitHubのデータ保護戦略を強化できます。

    GitHub ポリシーに関する重要な注意事項

    GitHub の次世代 API データ保護ポリシーを設定する際は、以下の制限事項と動作に留意してください。

    • 内部ユーザーへのアクセスを制限するアクション

      この操作では、リポジトリからexternal collaboratorsのみが削除されます。

    • エンティティサポート
      次世代GitHub 現在、 commits pushed to a repositoryにのみ適用されます。

    Microsoft 365 OneDrive & SharePoint 商用版

    • ゲスト/外部ユーザーの解析に関する制限:ユーザープロファイルに含まれるゲスト/外部ユーザーは、OneDriveおよびSharePointにおける露出計算の対象とはなりません。これは現在知られている制限事項です。回避策として、ゲスト/外部ユーザーのドメインをドメインプロファイルに追加することができます。

    • 継承されたリンクを削除する: Microsoft 365 OneDrive および SharePoint では、ファイルは親フォルダーから共有リンクを継承できます。修復措置を実行する際(インベントリページから手動で行う場合、またはポリシーを介して行う場合)、特定のユーザーのみの継承されたアクセス権を取り消す必要がある場合は、他のユーザーのアクセス権を維持するために、ファイルレベルで新しい共有リンクが生成されることがあります。

    • 削除されたグループの露出計算: Netskope API データ保護をプロビジョニングする前に削除されたグループと共有されたファイルの場合、 InventoryページのファイルのExposure Statusは空白になります。この問題を解決するには、Microsoft テナント管理者が、Microsoft テナント内で削除されたグループのアクセス許可を取り消す必要があります。その後、Netskopeはファイルの露出度を正確に計算し、ポリシーアクションを実行できます。

    Slackエンタープライズチャンネルのプロモーションおよび会話に関するポリシー

    チャンネルが複数のワークスペースで共有されている場合、または外部ユーザーが含まれている場合、Slack はそのチャンネルを組織レベルに昇格させます。次世代APIデータ保護では、既存のチャネルは削除され、昇格されたチャネル用に新しいチャネルが作成されます。

    次世代 API データ保護では、特定のポリシーを個々のチャネルにバインドできます。 プロモーション中にチャンネルが削除された場合、そのチャンネルに以前設定されていたポリシーは無効になり、新しくプロモーションされたチャンネルに自動的に引き継がれません。

    これは、チャネル固有のポリシーを設定する場合にのみ適用されます。

    Salesforceファイル公開に関するガイダンス

    Next Generation API Data Protection の Salesforce ファイル公開機能を使用すると、Salesforce でのファイルの共有方法に基づいてポリシーを定義できます。 このセクションでは、現在の制限事項と、ポリシーを効果的に設定するための推奨されるベストプラクティスについて概説します。

    Important Notes

    • 露出度はfile のみサポートされています。

    • page 、 comment 、 、 chat message bodyの露出はサポートされていません。それらの曝露値は常にUnknownとして報告されます。

    ファイル露出タイプ

    • ContentDocument (Salesforce Files)

      ContentDocumentは、ClassicとLightningの両方のエクスペリエンスでFilesタブで使用できるSalesforceファイルを表します。

      Exposure definitions:

      • Anonymous ファイルには直接公開リンクがあります。

      • External ファイルは、外部ユーザーまたは外部ユーザーを含むグループと直接共有されます。

      • All Internal Users ファイルは組織全体で直接共有され、すべての内部ユーザーがアクセスできます。

      • Internal ファイルは共有ライブラリにアップロードされるか、所有者以外の内部ユーザー/グループと直接共有されます。

      • Owner ファイルは他者と共有されることなく、「自分の所有物」にアップロードされます。

      Limitations (Salesforce API constraints):

      • 親ライブラリから継承された権限はnot supportedです。ライブラリのアクセス権限を通じてアクセス権を持つユーザーまたはグループを特定することはできません。

      • 親フォルダの公開リンクはnot supportedです。

      • ファイル共有の削除数はnot trackedであり、これが不正確な露出報告の原因となる可能性があります。この問題は今後のリリースで対応予定です。

    • Document (Salesforce Classic Document)

      DocumentはSalesforceクラシックドキュメントを表します。

      Exposure definitions:

      • Anonymous – Salesforce UIで「外部公開画像」としてマークされている場合、ドキュメントは一般公開されます。

      • External - 適用できない。Salesforce APIでは、直接アクセス権限を持つユーザーやグループに関する情報は提供されません。

      • All Internal Users – 親フォルダはすべてのユーザーがアクセスできるように設定されています。

      • Internal 親フォルダは特定のユーザー/グループのみにアクセスが制限されています。Salesforce API を介して実際のユーザーリストを取得することはできません。

      • Owner – 親フォルダはすべてのユーザーから非表示になっているか、ファイルが「マイ個人文書」にアップロードされています。

    • Attachment (Salesforce Classic Attachment)

      Attachmentは、Salesforce ClassicのNotes & Attachmentsセクションからアップロードされたファイルを指します。露出は常にInternalに設定されています。

      • 露出は常にInternalに設定されます。

      • Salesforce APIの制限により、親オブジェクトから継承されたアクセス権を解決できません。

      Salesforceの公開ポリシーに関するベストプラクティス

      Salesforce はファイルに対してのみ露出フィルタをサポートしているため、完全にカバーするには 2 つのポリシーのアプローチを使用することをお勧めします。

      1. ファイルに関するポリシー:

        • Resource TypeをFile/Attachmentに設定します。

        • 希望するexposure filtersを適用してください(例:匿名、内部、所有者など)。

      2. その他のエンティティ(ページ、コメント、チャットメッセージ本文)に関するポリシー:

        • Resource TypeをChat Message Body 、 Page 、 Commentに設定します。

        • notは露出フィルターを適用します。Exposure値をAllに設定してください。そうしないと、コンテンツがスキャンされない可能性があります。

      ポリシー作成後は必ずポリシーを検証し、露出フィルターがサポートされている場合にのみ適用されることを確認してください。これにより、スキャン漏れを防ぎ、正確な結果を保証します。

    依存関係テーブル違反に関するServiceNowアラートURLの動作

    ServiceNowの依存関係テーブル内の機密データでDLP違反が検出された場合、生成されるアラートURLは、親リクエストアイテムではなく、データが見つかった特定のテーブルレコードを指します。

    例えば、リクエストアイテム(RITM)チケットのカタログ変数値は、 sc_item_option 、 sc_item_option_mtom 、 sc_multi_row_question_answerなどの依存関係テーブルに格納されます。これらのテーブルのいずれかで機密データが検出された場合、アラートは親テーブルではなく、その依存関係テーブルのレコードに直接リンクしますsc_req_item 。

    この動作は想定内のものであり、コネクタが監視対象のServiceNowテーブルを独立したエンティティとして扱うために発生します。関連テーブル間の親子関係は解決されません。

    対照的に、インシデント( incident )レコードはメインテーブル内にデータを直接保存するため、アラートURLはインシデントレコード自体を指します。

    この動作は設計上の仕様であり、製品の欠陥ではありません。

    ポリシーアクション 特別な行動

    Use caseGitHubGoogleドライブMicrosoft 365 OneDrive および SharePointワークデイ
    所有者を特定のユーザーに変更する-Google共有ドライブには所有者が存在しないため、Netskopeは共有ドライブ内のファイルやフォルダの所有者を変更することはできません。この操作はMy Driveのみに適用されます。-Workdayは、新しい所有者のみにアクセス権限を自動的に制限します。以前の所有者を含む他のユーザーは、今後そのファイルにアクセスできなくなります。
    内部ユーザーのみにアクセスを制限する外部協力者のみを削除します。---
    所有者のみにアクセスを制限-Google共有ドライブには所有者が存在しないため、Netskopeは共有ドライブ内のファイルやフォルダへのアクセスを所有者に制限することはできません。この操作はMy Driveのみに適用されます。--
    継承された権限へのアクセスを制限する-Netskopeは、Googleドライブ(マイドライブと共有ドライブの両方を含む)内のファイルやフォルダから、継承されたアクセス許可を削除しません。継承されたアクセス許可は、それが生成された親フォルダーのレベルで制御され、そこで管理する必要があります。権限削除要求に継承された権限が含まれている場合、権限変更はバッチ処理されるため、操作全体が失敗します。直接的なアクセス許可を確実に削除するには、継承されたアクセス許可をリクエストから除外し、代わりに親フォルダーレベルで更新してください。--
    ファイルレベルで追加されたユーザーの取り消し--ファイルレベルで追加されたユーザーの取り消しアクションがトリガーされると、Netskope は以下のアクセス権を削除します。

    • (オーナーを除く)人々

    • Office 365 グループ(所有者、全員、外部ユーザーを除く全員を除く)

    • リンク(リンクを持つすべての人、組織内でリンクを持つ人を除く)


    ファイルレベルで追加されたユーザーのアクセス権を取り消すアクションの目的は、特定のユーザーまたはグループに付与されたアクセス権を削除することです。ただし、特別な Office 365 グループ「Everyone」については、次世代 API データ保護はこれを特定のユーザーまたはグループを指すものとして扱いません。その結果、次世代APIデータ保護は、「全員」グループのアクセス権を変更または削除しません。 この動作は、従来のAPIデータ保護とは異なり、「全員」グループを削除します。
    -
    共有ドライブ内のファイルとフォルダーに対するポリシーアクション-Netskopeは、共有ドライブ上にマネージャー/コンテンツマネージャー/ライターの役割を持つユーザーが存在する場合にのみ、共有ドライブ内のファイルまたはフォルダーにポリシーアクションを適用します。Netskopeは、そのユーザーになりすましてポリシーアクションを実行します。共有ドライブ上でこれらの役割を持つユーザーに権限が付与されていない場合、ポリシーに違反した場合でも、Netskopeはポリシーアクションを実行しません。--
    このトピックでは
    • 次世代 API データ保護ポリシーの作成