kintone を利用するには、kintone のライセンスが必要となります。
しかし、kintone の契約ユーザーではない外部のユーザーと kintone 内の一部のデータを共有したり、 不特定多数の人から kintone へデータを登録してもらいたい場合もあるかと思います。
たとえば、次のようなケースが考えられます。

• セミナーや採用の募集など社外から応募してもらうケース（外部からデータを登録する）
• 取引先に取引に関する情報を公開するケース（外部にデータを公開する）
• 予約システムとして利用し、予約者が自身の予約情報を参照するケース（外部にデータを公開する）

このような要件は、Web ページを用いて外部から kintone のデータを操作することで実現できます。

実装には Web のしくみや kintone API 仕様の理解など幅広い知識が求められますが、連携サービスを利用した比較的簡単な実装も可能です。
しかし、独自にシステムを構築する場合も、連携サービスを利用する場合も、セキュリティ面の考慮を怠ると想定外の情報漏洩などの事態を招きかねません。
ここでは、Web ページを用いた外部からのデータ操作をセキュアにするため考慮すべき注意事項を紹介します。

データを登録してもらうだけの場合でも、外部ユーザーにデータの参照などの余計な権限を付与してしまうことで kintone 内のデータに対して悪意のある操作をされてしまう可能性があります。
そこで、以下のような対策が必要です。

kintone REST API では複数の認証方法が使用できます。
今回のように kintone の契約ユーザーではない外部のユーザーが利用する場合は、API トークンの使用を推奨します。

kintone の API トークンとは

アプリごとに発行する「トークン」と呼ばれる文字列を、REST API のリクエストヘッダーに指定することで、REST API を実行できる認証方法です。
APIトークンを使ってみよう

API による操作権限について、外部ユーザー向けのアンケートを行う利用を想定して説明します。
外部ユーザーから Web ページ上で記入してもらった回答内容を REST API を使用して kintone に登録するとき、 必要な権限は「回答内容を登録するアプリ」の「レコード追加」権限のみとなります。
「閲覧」「編集」「削除」等の不要な権限を有していると、悪意のある人にデータを操作される可能性が高まります。
他のアプリの権限も有する認証だった場合、想定外の情報まで操作されてしまうかもしれません。

その点 API トークン認証では、権限を 1 つのアプリに限定できます。
また、「追加」のみで「閲覧」権限は与えないなど、細かな権限制御によって外部操作の影響範囲を特定できます。
対象となるアプリの利用目的を明確にし、適切な権限のみを付与するようにしましょう。

連携用の kintone ユーザーアカウントを用意してパスワード認証を使用する方法も考えられますが、 API トークンのように権限を 1 つのアプリに限定できないため推奨しません。
ユーザーアカウントの認証情報が流出すると、そのアカウントでアクセスできるすべての情報が操作可能となってしまいます。

外部ユーザーにデータを公開する場合は、kintone の環境外へデータを渡すことになります。
そのため、セキュリティ面に考慮しないと情報漏洩のリスクが伴います。
そこで、以下のような対策が必要です。

kintone は企業や自治体の情報システム基盤として利用されるケースも増えています。 利用する人が増えれば、悪意を持って Web ページを操作される可能性も高まります。
利用目的から影響度を予測し、次のような対策で公開範囲や情報を制限しましょう。

公開する Web ページへのアクセスを制御する

アクセス制御のない Web ページは、URL さえ知っていれば誰でもアクセスできる状態となってしまいます。
特定のユーザーのみに公開したい場合は、認証や IP アドレス制限の設定が必要です。

kintone アプリに機密情報を含めない

外部公開にはリスクが伴うことを理解し、扱う情報をあらかじめ選別することが大切です。
外部から操作するアプリには個人情報や秘匿性の高い情報は含めず、別アプリで管理することを推奨します。
個人情報や秘匿性の高い情報を公開する必要がある場合は、後述する中継するしくみの構築を検討してください。

kintone アプリのレコードの一部を絞り込んで公開する場合、絞り込みを行っているので画面上では問題ないように見えても、ブラウザー開発者ツールを利用すると想定していないレコードを閲覧されてしまう可能性があります。

担当 ID をもとに取引情報を公開するケースを例に紹介します。
担当 ID を入力し取引情報を取得ボタンを押下すると、kintone アプリに保存された取引情報を表示します。
このとき「担当 ID=入力値」という絞り込み条件でレコードが検索されます。

画面から操作する場合

担当 ID が未入力の場合はエラーとすることで、絞り込み条件のない取引情報の表示を防ぐことができます。
なお、誤入力や無差別入力によって想定外の取引情報を閲覧される可能性はあります。

ブラウザー開発者ツールを利用して操作する場合

ブラウザーの開発者ツールを利用すると、JavaScript のエラーチェックが適用されません。
そのため、担当 ID による絞り込みを強制できず、全レコードの表示が可能となってしまいます。

kintone の連携サービスを利用する場合も同様で注意が必要です。
連携サービスを利用して個人情報や秘匿性の高い情報を公開する場合は、上記のように開発者ツールにて想定外のレコードが閲覧可能になっていないか確認することを推奨します。
このような開発者ツールを利用した情報閲覧を防ぐには、中継するしくみで絞り込み条件を強制する方法が考えられます。

中継するしくみとは

クロスドメイン制約によりブラウザー（JavaScript）から kintone REST API は実行できないため、 外部の Web ページから kintone のデータを操作するには、リクエストを中継するしくみが必要となります。
中継するしくみには Web サーバーを構築する方法やサーバーレスサービスを利用する方法があります。

中継するしくみにて担当 ID を使った絞り込み条件を必須とすれば、ブラウザーの開発者ツールでも全レコードの取得はできません。

編集や削除などの余計な権限を付与してしまうことで、kintone 内のデータに対して悪意のある操作をされてしまう可能性があります。
付与する権限は最低限にしましょう。詳細は 前項 を確認してください。

ここでは、Web ページを用いた外部からのデータ操作をセキュアにするため考慮すべき注意事項を紹介しました。

• 利用目的に応じて、Web ページの公開範囲や kintone アプリで扱う情報を制限する。
• レコードの一部を絞り込んで公開する場合、想定外のレコードが閲覧される可能性を理解する。
  • 連携サービスを利用する場合は、ブラウザーの開発者ツールを使用した無条件のレコード閲覧が発生しないか確認する。
  • 無条件のレコード閲覧を防ぐ必要がある場合は、中継するしくみを構築する。
• REST API の実行には API トークン認証を使用し、適切な権限のみを付与する。

まずはリスクを分析して、適切な対応を選択するようにしましょう。
情報漏洩を未然に防ぐこと、万が一の発生時にも影響範囲を限定することが大切です。