アクセスが制限されているフォルダとアクセスが広範なフォルダを管理する

ユーザーがマイドライブ フォルダを所有している。フォルダには、異なるファイルにアクセスできる複数のユーザーが含まれている場合があります。この制限付きアクセスモデルでは、同じフォルダ内のアイテムのリストがユーザーごとに異なる可能性があります。親のマイドライブ フォルダにはアクセスできるが、そのフォルダ内のアイテムにはアクセスできないユーザーは、「アクセス制限あり」となります。これにより、階層内で誰がアクセス権を持っているかを把握することが難しくなります。

一方、共有ドライブのファイルは共有ドライブが所有します。共有ドライブは拡張モデルを採用しているため、同じフォルダ内のアイテムのリストはすべてのユーザーで同じになります。

アクセスが制限されているフォルダの導入により、共有ドライブの広範なアクセスモデルがマイドライブに複製されます。この変更により、アクセスが制限されているフォルダは、マイドライブと共有ドライブの両方で特定のサブフォルダへのアクセスを制限できる唯一の例外となります。

このガイドでは、Google ドライブで制限付きアクセスと拡張アクセスを使用するフォルダを管理する方法について説明します。

アクセス制限付きのフォルダについて

フォルダを特定のユーザーに制限します。

アクセス制限付きのフォルダを使用すると、フォルダを特定のユーザーに制限できます。フォルダを開いてコンテンツにアクセスできるのは、フォルダの権限に直接追加したユーザーのみです。共有マイドライブ フォルダまたは共有ドライブ フォルダへのアクセス権を継承したユーザー(親フォルダからのアクセス権を介して)は、ドライブ内の制限されているフォルダを表示できますが、開くことはできません。この機能により、マイドライブと共有ドライブの両方でアイテムの共有動作の整合性が向上し、機密情報を含むフォルダをより広範に共有されるコンテンツとともに整理できるようになります。

アクセスが制限されているフォルダは、マイドライブと共有ドライブの両方で使用できます。マイドライブの owner の役割と共有ドライブの organizer の役割は、アクセス制限のあるフォルダに常にアクセスできます。フォルダ ユーザーのリストを変更するために、特別な権限は必要ありません。フォルダを共有できるロールは、メンバー リストを更新できます。ロールと権限の詳細については、ロールと権限共有ドライブの概要をご覧ください。

フォルダはファイルの一種ですが、ファイルに対してアクセス制限は使用できません。

フォルダへのアクセス制限を設定する

フォルダの権限が直接付与されているユーザーはアクセス制限付きのフォルダにアクセスできますが、アクセス制限を有効または無効にできるのは、マイドライブの owner ロールと共有ドライブの organizer ロールのみです。

また、マイドライブで writer ロールを持つユーザーが、files リソースの writersCanShare ブール値フィールドを true に設定している場合、この機能をオンまたはオフにすることもできます。

フォルダへのアクセスを制限するには、files リソースのブール値 inheritedPermissionsDisabled フィールドを true に設定します。true の場合、アクセスできるのは owner ロール、organizer ロール、フォルダに直接権限を持つユーザーのみです。

継承された権限を再度有効にするには、inheritedPermissionsDisabledfalse に設定します。

フォルダへのアクセスを制限する権限を確認する

フォルダへのアクセスを制限できるかどうかを確認するには、files リソースの capabilities.canDisableInheritedPermissions フィールドと capabilities.canEnableInheritedPermissions フィールドのブール値を調べます。これらの設定は、inheritedPermissionsDisabled フィールドを使用してフォルダへのアクセスを制限する権限があるかどうかを確認します。

capabilities の詳細については、ファイル機能についてをご覧ください。

アクセス制限付きのフォルダの子を取得する

フォルダの子を一覧表示できるかどうかを確認するには、capabilities.canListChildren ブール値フィールドを使用します。

アイテムがフォルダでない場合、またはリクエスト元のフォルダのコンテンツへのアクセス権が inheritedPermissionsDisabledfalse に設定することで削除された場合、返される値は常に false になります。

フォルダのコンテンツへのアクセス権が削除された場合でも、files.get() メソッドと files.list() メソッドを使用して、フォルダのメタデータにアクセスできます。アクセスが制限されていることを確認するには、レスポンスの本文で、アイテムが MIME タイプ application/vnd.google-apps.folder のフォルダで、capabilities.canListChildren フィールドが false に設定されているかどうかを確認します。このようなフォルダの子を一覧表示しようとすると、結果は常に空になります。

アクセス制限付きのフォルダのメタデータにアクセスする

アクセス制限付きのフォルダでは、フォルダのコンテンツにアクセスできない場合でも、フォルダのメタデータを表示できます。

permissions リソースを使用してユーザーのアクセス権を判断する場合、メタデータへのアクセス権のみを付与する [マイドライブ] フォルダと共有ドライブ フォルダの両方で、レスポンス本文に inheritedPermissionsDisabled=trueview=metadata の値が含まれます。ロールは常に reader に設定されます。view フィールドは、view に属する権限に対してのみ入力されます。詳細については、ビューをご覧ください。

permissionDetails フィールドのすべてのエントリで、inherited フィールドが true に設定されています。これは、権限が継承され、フォルダの内容への直接アクセス権が付与されていないことを示します。

フォルダのコンテンツとメタデータの両方へのアクセス権を付与するには、inheritedPermissionsDisabled フィールドを false に設定するか、ロールを reader 以上に更新します。

最後に、フォルダの継承をオフにして(inheritedPermissionsDisabled=true)権限が最初に制限され、その後、権限がフォルダに直接追加された場合、レスポンス本文の値は inheritedPermissionsDisabled=true になり、view フィールドは設定されません。フォルダが共有ドライブにある場合、permissionDetails リストには inherited フィールドが false に設定されたエントリがあり、権限が継承されていないことを示します。この権限は、他の権限と同様に、フォルダのコンテンツとメタデータの両方へのアクセスを許可します。

アクセス制限付きのフォルダを削除する

アクセス制限付きのフォルダは、files リソースの files.delete() メソッドを使用して削除できます。

マイドライブ内のフォルダ階層を削除できるのは、そのアイテムのオーナーのみです。アクセス制限付きのフォルダを含む階層を、そのフォルダのオーナー以外のユーザーが削除した場合、それらのフォルダはオーナーのマイドライブに移動します。

ユーザーに owner ロールがある場合、階層全体が削除されます。

共有ドライブでは、organizer ロールのユーザーは、アクセス制限付きのフォルダが含まれている場合でも階層を削除できます。fileOrganizer ロールがアクセス制限付きのフォルダを含む階層を削除した場合、結果は、アクセス制限付きのフォルダに fileOrganizer として追加されたかどうかによって異なります。削除された場合は、階層全体が削除されます。制限付きアクセス権を持つフォルダは、共有ドライブのルートフォルダに移動します。

アクセス制限のないアクセスについて

アクセスが制限されているフォルダの導入により、共有ドライブの広範なアクセスモデルがマイドライブにも拡大されます。アクセスモデルがロールアウトされると、フォルダへのアクセス権は、そのフォルダ階層内のすべてのものに対する少なくとも同じレベルのアクセス権を意味します。アクセス制限付きフォルダは、マイドライブと共有ドライブの両方で特定のサブフォルダへのアクセスを制限できる唯一の例外です。また、フォルダへのアクセスが制限されていない限り、親フォルダから継承されたアクセス権を削除することもできなくなります。この場合、ドライブ API はエラー レスポンスを返します。階層内でよりきめ細かいアクセス制御を定義するには、フォルダにアクセス制限を設定します。

アクセス拡大に対応する

デベロッパーが拡張アクセスに簡単に適応できるように、Google Drive API にいくつかの改善が加えられました。

  1. permissions リソースの permissionDetails[] フィールドに、マイドライブ内のアイテムの値が設定されるようになりました。以前は、フィールドは設定されていないか、必要に応じて teamDrivePermissionDetails フィールドから複製されていました。[マイドライブ] の permissionType フィールドと inherited フィールドのみが入力されます。

    permissionDetails[].inherited フィールドは、権限がアイテムの親から継承されているかどうかを示します。特定のロール(reader など)が親から継承されているかどうか、上位のロール(writer など)がアイテムに直接付与されているかどうかを検出できます。

    アイテムの権限を表示すると、permissionDetails[] フィールドに複数のエントリが含まれていることがあります。存在する場合、そのスコープのアイテムに対する権限のエントリが 1 つあり、アイテムに対する継承された権限またはメンバー権限のエントリがあります。

  2. デベロッパーは、将来の強制適用に先立って、マイドライブで広範なアクセス API の動作を有効にできます。enforceExpansiveAccess リクエスト パラメータを true に設定すると、今後、広範なアクセス権に変更が加えられても、アプリに影響が及ぶことはありません。

    今すぐオプトインすると、API は共有ドライブ内のアイテムに対してすでに実行しているのと同じように、マイドライブ内のアイテムに対しても動作します。たとえば、permissions.update() を呼び出すときに、継承されたロールよりも低いアクセス制限を試みると失敗します。同様に、権限が継承されている場合、permissions.delete() の呼び出しは失敗します。

制限付きアクセスの検出と防止

アプリが permissions.update() メソッドまたは permissions.delete() メソッドを使用している場合、マイドライブ フォルダにアクセス制限(ユーザーが親のマイドライブ フォルダにはアクセスできるが、そのフォルダ内のファイルにはアクセスできない)が作成される可能性があります。

これらのメソッドを使用すると、permissions リソースのフィールドを確認して、リクエストによって制限付きアクセスが作成される可能性のある場所を特定し、そのようなリクエストの送信を回避できます。この状況を検出するには、リクエストの enforceExpansiveAccess フィールドを使用します。

また、アプリがフォルダへのアクセスをすでに制限している場合は、次の手順を行います。

  1. フォルダの階層をたどって、アクセス制限を削除します。代わりに、フォルダへのアクセスを制限する必要があります。

  2. 共有を解除しようとしているアイテムがファイルの場合は、中間フォルダを作成してアクセス制限を設定し、その新しいフォルダにファイルを移動します。

  3. アクセス制限付きフォルダを使用しないが、一部のアクセス権を削除する必要がある場合は、ファイルを非公開フォルダ(マイドライブのルートフォルダなど)に移動できます。その後、ユーザーが引き続き使用できるように、アイテムの元の場所へのショートカットを作成できます。