セキュリティ: 基本情報

[Security] タブには複数のセクションがあり、それぞれでカスタマイズを行えます。[Require Sign-In] セクションで、アプリを使用するユーザーに対してログインを必須にできます。セキュリティ フィルタを使用したり、[Domain Authentication] タブでドメイン グループを定義してユーザーのアクセスを制御したりすることもできます。

AppSheet のセキュリティは、以下によって確保されます。

1. 認証: アプリケーションのユーザーを確実に識別できます。
2. アプリケーションのアクセス制御: 誰がアプリケーションを実行できるかを制御できます。
3. データのアクセス制御: 各ユーザーがどのデータを確認できるかを制御できます。
4. 監査: アプリケーションの使用状況をモニタリングできます。

AppSheet のセキュリティの仕組み

このセクションでは、AppSheet のセキュリティがどのように機能し、

1）AppSheet のアーキテクチャ、2）クラウドとモバイル テクノロジーの基礎となるセキュリティ インフラストラクチャ、3）セキュリティ対策のオプションによって AppSheet の安全がいかに保たれるかを説明します。

まず、セキュリティの観点から、AppSheet のアーキテクチャの概要を簡単に紹介します。

• クラウドデータ。AppSheet データベースを使用する場合、AppSheet はユーザーのデータを Google Cloud に保存します。AppSheet データベースを使用しない場合、AppSheet アプリケーションに保存されたデータは、主に Google スプレッドシートなどのクラウド ストレージ サービスか Cloud SQL などのクラウド データベースのいずれか希望する場所に保存されます。場合より、AppSheet がパフォーマンス確保のため、および監査ログなどの機能に対応するため、一時的にお客様のアプリケーション データを保存することもあります。これらの機能は、アプリケーションの設定で制御できます。アプリケーションの設定（外観、ブランド表示、共有など）と特定のユーザー情報（チーム、データソース構成、管理ポリシーなど）は、AppSheet によってセキュリティ保護された形で Google Cloud に保存されます。
• 承認。アプリケーションの作成時は、クラウド ストレージ アカウントを使用して AppSheet にログインし、自身に代わってクラウド ストレージのデータの読み書きを行う権限を AppSheet に付与します。この処理では、業界標準の OAuth プロトコルが使用されます。詳細は、クラウド プロバイダに対する AppSheet の権限をご覧ください。
• アプリは、クラウドに保存されたデータを基に作成されます。作成したアプリケーションは、AppSheet によって維持管理されるアプリケーションの定義に従い、安全なクラウド データベースに保存されます。AppSheet クラウド サービスとお客様のクラウド ストレージ プロバイダ間の通信では、セキュア ウェブ プロトコル（HTTPS）が使用されます。
• アプリは、モバイル デバイスで動作します。. モバイル デバイスと AppSheet クラウド サービス間の通信では、セキュア ウェブ プロトコル（HTTPS）が使用されます。
• ローカル データ ストレージ。アプリケーションの定義と必要なすべてのデータがモバイル デバイスにコピーされ、HTML5 ローカル ストレージを使用して、安全に保護された形でデバイスにローカル保存されます。
• データの同期。モバイル デバイスで動作する AppSheet アプリケーションからデータを追加、更新、削除すると、すべての変更内容がクラウド データ プロバイダに保存されます。AppSheet クラウド サービスは、モバイルアプリとお客様のアプリによって使用されるクラウド データ プロバイダの橋渡し役として機能します。

ヒントとコツ

アプリ保護のヒントとコツを AppSheet コミュニティから得ることができます。セキュリティに関するヒントとコツをご覧ください。

AppSheet のセキュリティに関するよくある質問

以降のセクションでは、グラフィック デザインの授業で生徒に課題を配布し、生徒から課題を回収するために教師が作成した架空のアプリを使用して、AppSheet のセキュリティに関するよくある質問（FAQ）を紹介します。

私のクラウドデータには誰が直接アクセスできますか。

他の AppSheet ユーザーは、お客様のクラウドデータには直接アクセスできません。アクセス権限は、お客様（およびお客様のクラウド アカウントのログイン情報を持つ他のユーザー）にのみ付与されます。

お客様がアプリで有効化した更新権限に応じて、アプリのユーザーが、クラウドにホストされたお客様のスプレッドシートに格納され、AppSheet でお客様が作成したアプリを使用して公開された値を追加、編集、削除できます。これらの権限は、この記事で後述するとおり管理できます。

AppSheet クラウド サービスには、お客様に代わってクラウドデータを読み書きする権限を有しています。これらの権限は、アプリの作成および実行といった特定目的にのみ使用されます。AppSheet は、データのコピーを保存しません。また、OAuth プロトコルの機能により、AppSheet に付与されたアクセス権限を随時無効化できます。 

誰が私のアプリにアクセスできますか。私はアクセスをどのように制御できますか。

アプリにアクセスできるユーザーの管理は、以下の 3 段階の手順で行います。

1. [Require user authentication] オプションを有効にします。
2. 認証プロバイダを選択します。
3. どのユーザーがアプリケーションを使用できるかを指定します。

まず、[Security] > [Require Sign-In] ペインに移動し、[Require user authentication] オプションを有効にして、[Require user authentication] オプションを設定します。これを行う場合は、アプリケーションのデプロイ時にユーザー単位料金プランのうち 1 つに登録する必要があります。[Require user authentication] は、アプリ単位料金プランでは設定できません。

次に、認証プロバイダを選択します。AppSheet は、ユーザー名とパスワードのユーザー レジストリを維持しません。代わりに、ユーザーは、Google、Dropbox、Office365、Box、Smartsheet などのクラウド プロバイダを使用してログインする必要があります。

• デフォルトでは、認証プロバイダは、データが保存されているクラウド データ プロバイダになります。たとえば、クラウド データ プロバイダが Google の場合、デフォルトの認証プロバイダは Google になります。
• または、Google、Dropbox、Office365、Box、Smartsheet を含む [Authentication Provider] プルダウンからいずれかのプロバイダを選択することもできます。たとえば、クラウド データ プロバイダが Google であっても、認証プロバイダとして Dropbox を選択できます。アプリのユーザー全員が Dropbox アカウントを持っている場合は、このオプションを選択できます。
• 最後に、Google、Dropbox、Office365、Box、Smartsheet を含むすべてのプロバイダを選択できます。このためには、[Authentication Provider] プルダウンの一番上に表示される空白の認証プロバイダを選択します。

最後に、どのユーザーがアプリケーションを使用できるかを指定します。

• 通常は、アプリケーションの使用を許可される各ユーザーのメールアドレスを「許可リスト」に入力します。これを行うには、[Security] > [Require Sign-In] ペインに移動し、[Manage users] をクリックします。次に、[People to invite] リストに各ユーザーのメールアドレスを入力します。複数のメールアドレスをカンマで区切って入力できます。次に、[Send install link] をクリックします。
• また、@mycompany.com などのドメイン名を入力して、ドメイン内のすべてのユーザーを含めることもできます。
• 最後に、[Allow all signed-in users] オプションを設定することで、許可リストの入力を省略できます。このオプションは、アクセスを特定のユーザーのリストに制限する必要がなく、しかしメールなどユーザー固有の情報へのアクセスが望まれる、またはセキュリティ フィルタやプライベート テーブルなどのパーソナライゼーション機能を使用する場合のみ有効にしてください。

アプリのユーザーがクラウド ストレージ内の私のデータにアクセスする必要もありますか。

いいえ。アプリ作成者は、お客様のクラウドデータに直接アクセスできないユーザーにアプリを配布できます。これは、デフォルトの実行モード（「as app creator」）では、AppSheet がアプリ作成者の ID を使用してデータにアクセスするよう指示されるため、問題なく機能します。通常、ユーザーには、お客様のクラウドデータへのアクセスを許可すべきではありません。代わりに、ユーザーには、アプリケーションを介して変更を行うことだけを許可してください。

まれに、アプリをアプリユーザーとして動作させる場合もあります。アクセスモード: app creator または app user をご覧ください。この場合は、ユーザーがクラウド ストレージ内のお客様のデータに直接アクセスすることを許可する必要があります。これは、お客様がその場合のセキュリティ上の影響を完全に理解している場合のみ行ってください。

ユーザーは、私のアプリで何をできますか。ユーザーは、私のデータを削除できますか。

アプリ作成者であるお客様が、ユーザーがお客様のデータに対しどのような変更を行えるかを制御できます。たとえば、ユーザーがお客様のデータを追加、更新、削除できるか、または読み取りのみできるかを制御できます。

以下の手順で、テーブルに対しどのような変更を行えるかを制御できます。

1. [Data] > [Tables] ペインに進みます。
2. テーブル名の左のアイコンをクリックします。
3. [Are updates allowed] プルダウンからアクセスモードを選択します。

以下の手順で、スライスに対しどのような変更を行えるかを制御できます。

1. [Data] > [Slices] ペインに進みます。
2. スライス名の左のアイコンをクリックします。
3. [Update mode] プルダウンからアクセスモードを選択します。

アプリの特定ユーザーが閲覧できるデータを制限できますか。

アプリのユーザーは、お客様がアプリを通じて公開することを選択したデータのみを閲覧できます。実際には、特定のクラスのユーザーには特定のデータ群のみを閲覧させ、他のユーザーには別のデータを閲覧させたい場合もあるでしょう。これはスライスを使用して行うことができます。

Class Assignments アプリの例では、生徒が完了した課題を提出し、過去の提出課題を引き続き閲覧できるようにしたいのですが、他の学生の完了した課題を閲覧できないようにする必要があります。これを実現する最善の方法は、ログインしたユーザーの課題のみを表示するスライスを作成することです。[Editor] > [Data] > [Slices] タブで [+ New Slice] をクリックします。

まず、スライスに名前を付けてから、複数のパラメータを指定する必要があります。この場合、[Submit] テーブルを選択します。ここに、新しい提出課題が格納されます。また、生徒に提出課題の追加のみ許可し、削除や編集はできないようにしたいため、スライスの更新モードとして [Adds] を選択します。

ログインした生徒が自分の現在および過去の提出課題のみを見ることができるようにするために、[Student] 列でフィルタリングする必要があります。アプリにログインするよう要求したため、フィルタ条件は [Matches user name] にします。これで、アプリが現在ログインしているユーザーの名前と一致するデータのみを表示するようになります。

メニューに、現在ログインしているユーザーの名前が表示されていることがわかります。下図のように、このスライスにより、Justin A. Sample が自分の過去の課題しか見ることができなくなります。

誰がモバイル デバイス上のデータにアクセスできますか。

モバイル デバイス上では、AppSheet は、ウェブブラウザに関連する業界標準の「ローカル ストレージ」技術を使用します（ウェブブラウザ技術は、AppSheet モバイルアプリに組み込まれており、実際の実装は、主に HTML5 技術を利用しています）。ユーザーがアプリにアクセスするにはログインする必要があるため、各ユーザーのデータは、他のユーザーのデータから分離されます。複数のユーザーが同じデバイスからアプリを使用する場合でも、異なるユーザーとしてデバイスにログインする限り、データは分離されます。つまり、デバイスの標準的なセキュリティ対策（ユーザーがパスワードでログインする）に従えば、アプリは、ウェブ技術を基盤とした他のすべてのアプリと同様に安全です。

アプリのユーザーが退職したためアプリの使用を停止したい場合はどうすればよいでしょうか。

いつでもユーザー許可リストに戻り、以前に追加したユーザーを削除できます。削除されたユーザーのモバイルアプリからの以後のアクションは、AppSheet クラウド サービスとの連携時（通常はデータの同期または保存時）に失敗します。

極端な手段にはなりますが、アプリのコピーを作成して、古いものを削除することもできます。古いものは動作しなくなり、新しいものへのアクセスを制御できます。まだアクセスが必要な他のユーザーに新しいアプリのリンクを再配布する必要があります。