kintoneセキュリティの設計方法｜認証・権限・監査ログ・外部共有の考え方

kintoneを本格的に使い始めると、必ずセキュリティの話が出ます。

顧客情報を入れてよいのか。

案件金額や粗利を誰に見せるのか。

社外メンバーを招待してよいのか。

退職者のアカウントはどう止めるのか。

IPアドレス制限や2要素認証は必要なのか。

APIトークンやWebhookで外部連携してよいのか。

監査ログで何を確認すべきなのか。

このとき、話が混ざりやすいのが「kintoneというサービスの安全性」と「自社の使い方の安全性」です。

kintoneのクラウド基盤は、認証、アクセス制御、監査ログ、インフラ運用、外部認証などの仕組みを持っています。

一方で、実際にどのユーザーにどの権限を渡すか、どのアプリを社外と共有するか、どの項目を見せないか、退職時に何を止めるかは、自社側の設計です。

ここを分けないと、次のような状態になります。

• 全社員が顧客情報や案件金額を見られる
• アプリ管理者が多すぎて、誰でもフォームや権限を変えられる
• レコード権限を設定したが、一覧やグラフで想定外の数字が見える
• フィールド権限を後から足したため、入力画面やCSV出力の挙動を確認していない
• ゲストスペースに社外メンバーを招待したが、退職・契約終了時の削除手順がない
• APIトークンに強い権限を付けたまま、連携先の管理者が曖昧
• 監査ログは存在するが、誰も定期的に見ていない
• IPアドレス制限を入れたが、リモートワークやスマホ利用の例外が整理されていない

セキュリティは、設定項目を強くすれば終わりではありません。

誰が、どの業務データを、どの場所から、どの操作までできるか。

これを業務単位で決める必要があります。

kintoneセキュリティで最初に決めるべきなのは、機能の有無ではなく、「どの業務データを誰にどこまで見せるか」です。

この記事では、kintoneセキュリティを、基盤の安全性、自社設定、2要素認証、IPアドレス制限、アプリ・レコード・フィールド権限、監査ログ、ゲストスペース、API連携、退職者・委託先管理まで含めて設計する方法を整理します。

kintoneデータベース設計はこちら
kintoneバックアップの設計方法はこちら

先に結論：基盤の安全性と自社の設定責任を分ける

kintoneセキュリティは、2層で考えます。

層	主な内容	主体
サービス基盤	データセンター、暗号化、監査、認証基盤、外部認証	サイボウズ
自社設定	ユーザー、認証設定、権限、外部共有、連携、棚卸し	利用企業

サイボウズ公式のセキュリティページでは、ISO/IEC 27001、ISO/IEC 27017、ISMAP、第三者機関によるセキュリティ監査、認証、アクセス制御、監査ログ、インフラ運用などが整理されています。

サイボウズ公式：kintoneセキュリティ

また、Kintone Trust Centerでは、アカウント管理、アクセス権、監査ログ、インフラ運用、第三者認証などの情報がまとめられています。

Kintone Trust Center

ここで大事なのは、基盤が整っていることと、自社のアプリが安全に運用されていることは別だという点です。

たとえば、基盤側に監査ログがあっても、ログを見る担当者がいなければ事故の兆候に気づけません。

アプリ・レコード・フィールド権限が用意されていても、Everyoneに広い権限を付ければ情報は広がります。

2要素認証が使えても、管理者だけ対象外にしていれば管理者アカウントが弱点になります。

kintoneが持つセキュリティ機能は土台です。自社の業務データを守るには、ユーザー、権限、外部共有、監査の運用設計が必要です。

ログイン認証と2要素認証

最初に見るべきなのは、ログイン認証です。

誰がkintoneへログインできるか。

どの端末、どの場所からログインできるか。

管理者アカウントをどう守るか。

cybozu.comのユーザー管理と認証ページでは、ログイン名とパスワードに加え、認証アプリによる2要素認証、IPアドレス制限、パスワードポリシーなどを組み合わせられると説明されています。

サイボウズ：ユーザー管理と認証

kintone公式のセキュリティページでも、SAMLによるシングルサインオン、SCIMによるユーザープロビジョニング、認証アプリによる2要素認証が紹介されています。

設計時には、次のように分けます。

対象	推奨する考え方
システム管理者	2要素認証を必須にする
アプリ管理者	2要素認証を必須に近い扱いにする
顧客情報や金額を扱うユーザー	2要素認証を基本にする
一時利用者	利用期間と削除日を決める
外部委託先	ゲストスペースや限定権限で扱う
API連携用ユーザー	人のログイン用途と分ける

2要素認証は、面倒だから後回しにされがちです。

しかし、kintoneに顧客情報、案件、契約、請求、証憑を入れるなら、ログインが突破されたときの影響は大きいです。

特に、管理者アカウント、外部公開に関わるアカウント、CSV書き出し権限を持つアカウントは強く守ります。

IPアドレス制限とセキュアアクセス

IPアドレス制限は、接続元を絞る機能です。

kintone公式のセキュリティページでは、アクセスできるIPアドレスを限定し、想定外のIPアドレスからのアクセスを防止できると説明されています。

IPアドレス制限は、次のようなケースで検討します。

ケース	考え方
社内ネットワークからだけ使う	IPアドレス制限が向く
拠点が固定されている	拠点IPを許可しやすい
リモートワークが多い	2要素認証やセキュアアクセスとの組み合わせを検討
モバイル利用が多い	IPが変わるため、IP制限だけでは運用しづらい
外部委託先が使う	ゲスト、権限、契約終了時の削除を重視
API連携がある	連携元IPや認証方式を確認する

IPアドレス制限は強力ですが、業務の場所を制約します。

出張、在宅、スマートフォン、外部パートナー、連携サービスなど、例外が増えると運用が複雑になります。

セキュアアクセスは、クライアント証明書によって接続端末を認証するオプションで、IPアドレス制限と組み合わせて社外アクセスを扱う選択肢になります。

サイボウズ：セキュアアクセス

重要なのは、IPアドレス制限を「入れるか入れないか」だけで決めないことです。

次の表で整理します。

項目	決めること
利用場所	本社、支社、在宅、外出先、店舗
利用端末	会社PC、私物PC、スマートフォン、タブレット
利用者	社員、委託先、取引先、ゲスト
例外手順	緊急時に誰が許可するか
連携元	API、Webhook、外部サービスの接続元
監査	想定外アクセスや失敗ログを誰が見るか

IPアドレス制限は、単独で万能ではありません。

認証、端末管理、権限、ログ確認と組み合わせて設計します。

アプリ・レコード・フィールド権限の設計

kintoneの業務セキュリティで最も重要なのは、権限設計です。

kintoneヘルプのアクセス権ページでは、アプリ、レコード、フィールドのアクセス権設定に関するヘルプが整理されています。

kintoneヘルプ：アクセス権の設定

kintone公式のセキュリティページでも、ロール、組織、ユーザー単位でアクセス権を設定でき、アプリ、レコード、フィールド単位で閲覧・編集・CSV書き出し・読み込みなどの操作権限を管理できると説明されています。

設計時には、3層で考えます。

権限	目的	例
アプリ権限	アプリに入れる人と操作を決める	閲覧、追加、編集、削除、CSV出力
レコード権限	レコード単位で見せる範囲を決める	自分の案件だけ、所属部門だけ
フィールド権限	項目単位で見せる・編集する範囲を決める	原価、粗利、個人情報、管理メモ

権限設計では、まず業務ロールを作ります。

ロール	見るもの	編集するもの
一般担当	自分の担当レコード	進捗、コメント、対応内容
部門責任者	部門内のレコード	承認、担当変更、重要項目
管理部	請求、契約、支払関連	経理項目、ステータス
経営	集計、重要案件、リスク情報	原則編集しない
アプリ管理者	設定、権限、連携	設定変更、メンテナンス
外部ゲスト	招待された範囲だけ	指定された入力・コメント

権限は、後からでも設定できます。

しかし、後から設定すると、既存の一覧、グラフ、通知、CSV出力、外部連携に影響します。

特に次の項目は、最初に見せ方を決めます。

項目	注意点
顧客の個人情報	全員に見せる必要があるか
案件金額	営業全員に見せるか、担当・責任者だけか
原価・粗利	経営、責任者、経理に絞ることが多い
契約書・請求書	添付ファイルの閲覧範囲も確認する
管理メモ	顧客対応者に見せてよいか
CSV出力	大量持ち出しにつながるため慎重に扱う

kintoneの権限設計は、「見せない設定」ではなく、業務ロールごとに見せる情報と編集できる操作を決める作業です。

削除・CSV出力・一括更新の権限は別に見る

セキュリティ事故は、閲覧権限だけで起きるわけではありません。

削除。

CSV出力。

ファイル読み込み。

一括更新。

アプリ設定変更。

WebhookやAPIトークン変更。

こうした操作は、業務への影響が大きいです。

操作	リスク	設計方針
レコード削除	データが消える	原則、管理者や責任者に絞る
CSV出力	大量持ち出し	必要なロールだけにする
CSV読み込み	一括誤更新	検証、バックアップ、作業承認を入れる
アプリ設定変更	権限や通知が壊れる	アプリ管理者を絞る
APIトークン	外部から更新できる	権限を最小化し、管理台帳を作る
Webhook	情報が外部へ出る	出す項目、通知先、ログ確認を決める

ファイル読み込みや一括更新は、便利ですが危険です。

更新前バックアップ。

対象一覧。

テスト更新。

更新後検証。

戻し手順。

ここまでセットにします。

kintoneバックアップの設計方法はこちら

監査ログとログ確認

監査ログは、事故後に見るものではなく、運用の一部として設計します。

kintoneヘルプでは、監査ログは、いつ、誰がどのような操作を行ったかを記録したログで、cybozu.com共通管理の画面で確認できると説明されています。

kintoneヘルプ：監査ログ

また、kintoneが出力する監査ログの一覧には、アプリ設定、レコード操作、ポータル、スペース、ゲストスペース、ユーザー招待、API操作などが整理されています。

kintoneヘルプ：kintoneが出力する監査ログの一覧

確認すべきログは、業務リスクに合わせて決めます。

見るログ	確認したいこと
ログイン	想定外の場所、時間、失敗回数
レコード削除	誰が何を削除したか
CSV出力	大量データを誰が出したか
CSV読み込み	誰がどのアプリへ取り込んだか
アプリ設定変更	権限、フォーム、通知、Webhookの変更
API操作	外部連携が想定外の更新をしていないか
ゲスト操作	社外ユーザーがどの範囲で操作したか

ログ確認は、担当者を決めます。

担当	見るもの
システム管理者	ログイン、管理者操作、IP制限
アプリ管理者	アプリ設定変更、CSV読み込み、Webhook
部門責任者	削除、重要レコードの更新、外部共有
情報管理担当	ゲスト、委託先、退職者、監査対応

ログはあるだけでは意味がありません。

月次で見るもの。

アラートとして見るもの。

事故時だけ見るもの。

この3つを分けます。

ゲストスペースと外部共有

社外メンバーと情報共有したい場合、ゲストスペースやゲストユーザーを使うことがあります。

サイボウズ公式のゲストスペース・ゲストユーザーページでは、通常ユーザーは全体ポータルや複数スペースにアクセスできる一方、ゲストユーザーは招待されたゲストスペース内の環境を利用すると説明されています。

サイボウズ公式：ゲストスペース・ゲストユーザー

kintoneヘルプでは、ゲストユーザー管理画面で、ゲストユーザーの一覧、ライセンス使用状況、ステータス、利用状況を確認し、不要なアカウントを削除できると説明されています。

kintoneヘルプ：ゲストの管理

外部共有では、次を決めます。

項目	設計内容
共有目的	何のために社外へ見せるのか
共有範囲	アプリ、レコード、フィールド、添付
ゲストの単位	会社別、案件別、プロジェクト別
招待責任者	誰が招待し、誰が削除するか
契約終了時	いつ削除するか
通知	社外メンバーへ何を通知するか
ログ確認	ゲスト操作を誰が見るか

外部共有で怖いのは、共有しすぎです。

「このアプリを見せればよい」ではなく、レコード単位、フィールド単位、添付ファイル単位で見ます。

特に、社外メンバーには、社内コメント、原価、管理メモ、他社情報、契約情報が見えていないか確認します。

APIトークン・Webhook・外部連携の権限

kintoneは外部サービスと連携しやすいです。

フォーム、チャット、会計、BI、帳票、メール、バッチ処理などとつなげられます。

ただし、外部連携はセキュリティ設計の対象です。

連携	見るべきこと
APIトークン	どのアプリに、どの操作権限を渡すか
連携ユーザー	人のアカウントと分けるか
Webhook	どの情報を外部へ送るか
フォーム連携	外部入力を直接本アプリへ入れるか
BI連携	kintone権限とBI側権限がずれないか
帳票連携	PDFや添付ファイルの保存先権限
チャット通知	外部チャンネルに出してよい項目か

APIトークンは、動かすために強くしすぎることがあります。

追加だけでよいのに、編集や削除まで付ける。

問い合わせ受付だけなのに、顧客マスタ全体を更新できる。

通知だけなのに、個人情報や金額を外部へ送る。

こうした状態を避けます。

kintoneフォーム連携の設計方法はこちら
kintone通知カスタマイズの設計方法はこちら

外部連携では、次の表を作ります。

項目	例
連携名	Webフォーム連携、会計連携、Slack通知
対象アプリ	問い合わせ、顧客、請求
操作	追加、閲覧、編集、削除
認証	APIトークン、OAuth、ユーザー認証
連携元	サービス名、IP、管理者
出す項目	氏名、会社名、金額、URL
ログ	成功、失敗、再実行
停止手順	トークン無効化、Webhook停止

外部連携は、作った人が退職すると分からなくなりやすいです。

管理台帳を残します。

退職者・委託先・権限棚卸し

セキュリティは、初期設定よりも棚卸しが重要です。

人は入社し、異動し、退職します。

委託先との契約は終わります。

部署やプロジェクトは変わります。

アプリは増えます。

外部連携も増えます。

そのため、定期的に棚卸しします。

棚卸し対象	確認すること
ユーザー	退職者、休職者、異動者が残っていないか
管理者	システム管理者、アプリ管理者が多すぎないか
ゲスト	契約終了後の外部ユーザーが残っていないか
アプリ権限	Everyoneに強い権限が残っていないか
レコード権限	部門異動後も見えていないか
フィールド権限	原価、個人情報、管理メモが広がっていないか
APIトークン	使っていない連携が残っていないか
Webhook	古い通知先へ情報を送っていないか
CSV権限	大量書き出しできる人が多すぎないか

権限棚卸しは、年1回では少ないことがあります。

重要アプリは月次または四半期。

一般アプリは半期。

退職・契約終了時は都度。

このように分けます。

kintoneのセキュリティは、一度設定して終わりではありません。退職、異動、委託終了、アプリ追加に合わせて棚卸しする必要があります。

よくある失敗

失敗1：Everyoneに強い権限を残す

初期構築では、動作確認のためにEveryoneへ広い権限を付けがちです。

そのまま本番運用に入ると、誰でも閲覧、編集、削除、CSV出力できる状態が残ります。

本番公開前に、Everyoneの権限を確認します。

失敗2：アプリ管理者を増やしすぎる

アプリ管理者は、フォーム、一覧、通知、権限、連携設定に触れます。

便利だからといって増やしすぎると、誰が何を変えたか分からなくなります。

アプリ管理者は、業務責任者と設定担当に絞ります。

失敗3：フィールド権限を後回しにする

原価、粗利、個人情報、管理メモは、後から隠そうとすると大変です。

一覧、グラフ、CSV出力、外部連携、通知文面にも影響します。

重要項目は、フォーム設計時点で見せ方を決めます。

失敗4：外部共有をゲストスペースだけで解決しようとする

ゲストスペースを使えば社外共有はできます。

しかし、何を見せるか、誰を招待するか、いつ削除するかを決めないと危険です。

ゲストスペースは、外部共有の手段です。

共有範囲と削除手順が本体です。

失敗5：監査ログを見ない

監査ログは、事故後だけに見るものではありません。

削除、CSV出力、ファイル読み込み、アプリ設定変更、API操作、ゲスト操作は、定期的に確認対象にします。

ログを見る担当者と頻度を決めます。

kintoneセキュリティ設計のチェックリスト

最後に、kintoneセキュリティ設計のチェックリストです。

チェック	確認すること
基盤理解	サービス基盤と自社設定を分けているか
認証	管理者、重要ユーザーに2要素認証を適用しているか
接続元	IPアドレス制限、セキュアアクセス、例外手順を決めたか
アプリ権限	閲覧、追加、編集、削除、CSV出力を分けたか
レコード権限	担当者、部門、外部共有で見える範囲を分けたか
フィールド権限	原価、粗利、個人情報、管理メモを分けたか
外部共有	ゲスト、委託先、取引先の削除手順があるか
外部連携	APIトークン、Webhook、連携ユーザーを管理しているか
監査ログ	誰が、何を、どの頻度で見るか決めたか
棚卸し	退職、異動、契約終了、アプリ追加時の見直しがあるか

セキュリティは、制限を増やすだけではうまくいきません。

現場が使えること。

必要な人だけが見られること。

重要操作を後から追えること。

この3つを両立させます。

kintoneダッシュボードの設計方法はこちら
kintoneプロセス分岐の設計方法はこちら

Bitlightに相談できること

Bitlightでは、kintoneセキュリティを、機能のオン・オフではなく、業務アプリを安全に運用する設計として整理します。

たとえば、次のような支援ができます。

相談内容	支援できること
権限が広すぎる	業務ロール、アプリ権限、レコード権限、フィールド権限を整理する
外部共有が不安	ゲストスペース、共有範囲、削除手順、監査ログを設計する
管理者が多い	システム管理者、アプリ管理者、部門管理者の役割を分ける
API連携が怖い	APIトークン、Webhook、連携ユーザー、停止手順を整理する
監査ログを見ていない	確認対象、頻度、担当者、異常時対応を決める
退職者や委託先が残りがち	入退社・契約終了時のアカウント棚卸し手順を作る

kintoneを安全に使うには、基盤の安全性に乗るだけでは足りません。

自社の業務データ、利用者、外部共有、連携、ログ確認を設計する。

その積み重ねで、kintoneを安心して使い続けられる業務基盤にできます。