kintoneの運用で、アプリの設計や権限設定は丁寧に決めたのに、ログインの入口だけが導入時のままという会社は少なくありません。初期に配ったパスワードをそのまま使い続け、追加した人には口頭で伝え、退職者の扱いはその都度対応。人数が少ないうちは回りますが、どこかで必ず管理が追いつかなくなります。本記事では、二要素認証・IPアドレス制限・SSO（シングルサインオン）がそれぞれ何を守る仕組みなのかを整理し、どの段階で何を検討すればよいかを解説します。
パスワード管理が限界になるのは、何人からか
ログインの管理を考え始める目安は、人数そのものよりも次のような兆候が出てきたときです。
- 入社・異動のたびに、誰がアカウントを作るのか毎回相談になっている
- パスワードをメールやチャットで送っている、あるいは共有ファイルに書いてある
- 社外や自宅から使う人が出てきたが、接続元の制限を決めていない
- 「このアカウント、まだ使っているのか分からない」というユーザーがいる
- kintone以外にも複数のクラウドサービスを使い始め、パスワードの使い回しが起きている
目安として、利用者が20〜30名を超えたあたりから、担当者の記憶と気配りだけでは追えなくなります。もっとも、人数が少なくても社外から接続する人がいる、あるいは人の入れ替わりが多い場合は、早い段階で仕組みに寄せたほうが安全です。放置した先で起きることは、退職者アカウント放置が招くセキュリティ事故で具体的に扱っています。
二要素認証・IPアドレス制限・SSO——それぞれが守る範囲の違い
この3つは混同されがちですが、守っている対象が違います。順に整理します。
二要素認証は、パスワードを知っているだけでは入れないようにする仕組みです。スマートフォンのアプリなどで生成される確認コードを追加で求めることで、パスワードが漏れた場合の被害を防ぎます。「誰が入ろうとしているか」を確かめる仕組みだと考えると分かりやすいです。
IPアドレス制限は、接続元のネットワークで入口を絞る仕組みです。社内ネットワークからだけ使えるようにする、といった使い方になります。「どこから入ろうとしているか」で判断するため、社外で使う人がいる場合は例外運用の設計が必要になります。
SSOは、認証を別の基盤（会社で使っているIDの管理サービスなど）にまとめる仕組みです。kintone専用のパスワードを持たせず、会社のアカウントでログインさせる形になります。守る範囲というより、入口を1か所に集めて管理しやすくする仕組みです。入口が1つになるので、アカウントの追加・停止もそこで一元化できます。
つまり、二要素認証とIPアドレス制限は「侵入を防ぐ」方向、SSOは「管理を集める」方向の対策です。目的が違うため、どちらかを入れればもう一方が不要になるという関係ではありません。実際には、SSOの基盤側で二要素認証を効かせる構成がよく採られます。
【判断基準】SSOを入れるべき会社・まだ不要な会社
SSOは効果が大きい一方で、設定と運用に手間がかかります。おおむね次の線が目安です。
SSOの検討を勧める場合
- すでに会社としてIDを管理する基盤があり、他のサービスでも使っている
- kintone以外にもクラウドサービスが3つ以上あり、それぞれにパスワードを配っている
- 入退社・異動が多く、アカウントの作成と停止が定常業務になっている
- 監査や取引先からの確認で、アクセス管理の説明を求められる場面がある
まだ二要素認証とIPアドレス制限で十分な場合
- 利用者が十数名で、追加・停止が年に数回しか発生しない
- 会社としてのID管理基盤がまだ無く、kintoneのために新設することになる
- 利用場所がほぼ社内に限られている
- そもそも誰がどのアカウントを使っているかの一覧が、まだ整っていない
最後の点は重要です。利用者の一覧が曖昧なままSSOを入れても、曖昧さがそのまま新しい基盤に移るだけです。順番としては、まずアカウントの棚卸しと停止手順を決め、そのうえで入口の仕組みを検討するほうが確実です。
導入前に決めること（対象者・例外運用・退職時の手順との接続）
仕組みを入れる前に、次の3点を文書にしておくと運用が安定します。
- 対象者の範囲——全員に同じ条件を適用するのか、管理者権限を持つ人だけ条件を厳しくするのか。権限の強い人から順に固めるのが現実的です。アプリ側の権限設計とあわせて考える場合は権限管理の考え方も参照してください
- 例外運用の決め方——社外から使う人、スマートフォンを持たない人、短期の協力会社など、標準の条件に収まらないケースを先に洗い出します。例外を「その都度判断」にすると、結局制限が形だけになります
- 退職・異動時の手順との接続——入口を変えるなら、停止の手順も同時に書き換える必要があります。誰が停止を依頼し、誰が実行し、どこに記録するのかまで決めておきます。実際に誰が何を変えたかを追えるようにしておく意味は監査ログの活用で触れています
なお、kintone（およびその基盤となるサービス）で利用できる認証の方式や設定項目、必要なプランの条件は、提供元の仕様によります。仕様は変わりうるため、実際の設計は必ず最新の公式情報をご確認ください。本記事は、どの対策が何を解決するのかという考え方の整理として読んでいただくことを想定しています。
まとめ——入口の対策は、アカウント台帳を整えてから
ログインの管理は、アプリの機能と比べて後回しにされがちな領域です。しかし、使われ方が広がれば必ず向き合うことになり、事故が起きてから整えるのでは遅い部分でもあります。
二要素認証は「誰が」を確かめる仕組み、IPアドレス制限は「どこから」を絞る仕組み、SSOは入口を1か所に集めて管理を楽にする仕組み。この違いを押さえたうえで、自社の人数・入れ替わりの頻度・利用場所に照らして選べば、過剰にも不足にもなりにくくなります。そして着手の順番は、まずアカウントの一覧と停止手順を整え、次に入口の仕組み、という流れが確実です。
DX Connectでは、kintoneのアカウント棚卸しから入口の設計、退職時の手順づくりまでご相談を承っています。「何から手を付けるべきか分からない」という段階でも構いませんので、現状をお聞かせください。
