メインコンテンツへスキップ
見出し画像

3-2.パスワードレス時代へ。Google Workspaceを活用したゼロトラスト認証基盤

    次期基幹システムの設計で、最初に固めた領域の一つが認証だ。地味に聞こえるかもしれない。だが、インターネットに公開されるクラウド基幹にとって、認証は玄関であり城壁だ。そして同時に、全社員が毎日触れる「使い勝手」の最前線でもある。第2回は、セキュリティと利便性を両立させた認証基盤の設計を書く。

    認証は、いまや「自前で作るか、委ねるか」という本質的な分岐を含む領域でもある。認証機構を実装する“手段”は、AIを使えば誰でもそれなりに書ける時代になりつつある。だが書けることと、堅牢な認証を自社で持ち続けることは違う。問われるのは「どこを自前で持ち、どこを最も成熟した基盤に委ねるか」という見極めだ。

    Before:パスワード運用の地獄

    旧来の認証まわりはこうだった。システムごとに別々のID・パスワード。社員は覚えきれず付箋に書く。定期変更ルールは形骸化し、末尾の数字だけ増えていく。最も危険なのが退職者のアカウントだ。退職処理とアカウント削除が別の手作業なので、退職後もログインできる「ゴーストアカウント」が残るリスクが常にあった。発行・変更・削除はすべて情シスへの依頼ベース。異動のたびに依頼が飛び、情シスは単純作業に追われる。セキュリティは弱く、運用は重い。最悪の組み合わせだった。

    After:基幹システムは「パスワードを持たない」

    次期システムの設計原則は明快だ。基幹システム内に、独自のパスワードを一切持たない。 認証はすべてGoogle Workspaceに委ねる。社員は会社のGoogleアカウントでSSO(シングルサインオン)し、基幹は「Googleが本人だと確認した人」を受け入れるだけ。システム側にパスワードのデータベースが存在しないのだから、パスワード漏洩という事故そのものが構造的に起こり得ない。

    アカウントの作成・停止はIDプロビジョニングでWorkspaceと連動する。人事側でアカウントが止まれば、基幹へのアクセスも即時に遮断される。退職処理とアクセス遮断が一つの操作になるので、ゴーストアカウントは原理的に発生しない。多要素認証(MFA)も基幹が独自に作り込む必要はなく、Workspace側で必須化すれば、その強度がそのまま入口の強度になる。第1回の「ブラウザ+クラウド」前提が、ここで最大限に効いている。

    ゼロトラストという考え方

    この設計の背景がゼロトラストだ。旧来は「社内ネットワークの中は安全」という前提に立っていた。だがクラウド時代、システムはインターネット上にあり、社員は社外からもアクセスする。「中と外」の境界線は、もう守りの単位にならない。ゼロトラストは前提を逆転させる。すべてのアクセスを信頼しない。毎回、誰が・どのデバイスから・正当にアクセスしているかを検証する。 その検証の中核を、自社で作るよりはるかに堅牢なGoogleの認証基盤に任せる。セキュリティを「自社で頑張って作り込む」のではなく「最も成熟した基盤に委ねる」。Shopifyに決済とインフラを委ねた判断と思想は同じだ。守りの主語を、適切な専門家に移す。これは「作れないから委ねる」のではない。「作れても委ねたほうが本質に資する」という、評価軸に基づいた判断だ。

    権限管理は「委譲して統制する」

    認証(本人確認)の次は、認可(何ができるか)だ。旧来は権限の付与・変更がすべて情シス集中だった。これを次期では拠点管理者へ運用を委譲する設計にした。拠点の異動は拠点が一番早く正確に知っている。その現場で権限を付け外しできれば、情シスの依頼待ちは消える。ただし委譲は放任ではない。誰がどの権限を誰に付与したかはすべて記録され、付与できる権限の範囲そのものは中央で設計する。運用は現場へ、統制は中央へ。 この分離が、負担軽減とガバナンスを両立させる。学んだのは「絞りすぎも緩めすぎも現場を壊す」ことだ。厳しすぎる権限は業務を止め、現場は共有アカウントなどの回避策に走る。業務の実態に合った粒度を、現場ヒアリング(前シリーズの財産だ)をもとに設計した。この「自社の業務に合った権限の粒度」は、まさに自社にしか決められない本質であり、汎用のツールがそのまま当てはめてくれるものではない。

    認証は「最初に」設計すべき領域

    早い段階でこの話を書いたのは、認証・認可が後から変えるのが最も難しい領域だからだ。全画面・全機能が権限モデルの上に建つ。途中で権限の考え方を変えると、作ったものすべてに影響が波及する。だから要件定義の最初期に、認証はWorkspaceへ委譲、権限は委譲と統制の分離、という骨格を固めた。

    次回からは業務領域の設計に入る。最初は事業の入口——「見積〜受注」の複雑なワークフローだ。



    評決ではなく、レンズを。

    認証機構を「作れる」ことと、どこを自前で持ちどこを委ねるかを「見極められる」ことは別物です。守りの主語をどこに置くかは、手段ではなく評価軸の問題です。

    AIで「作る」はコモディティになります。手段が横並びになるほど、散らばった知識の“点と点”をつなぎ、自社の本質——何を、どの基準で選び、どう活かすか——を見極める力が問われます。私はアトムビットとして、その見極めを特定ベンダーに肩入れしないフラットな評価軸でお渡しします。売るのは「どれが一番か」という評決ではなく、「あなたの制約でどう選ぶか」というレンズです。最終選定と結果責任は発注者にあります。

    選定とAIDDレディネスの要点を1枚にした無料の「評価軸チェックシート」を配布中です。

    ▶ 無料で受け取る:https://atomb.it/lens?utm_source=note&utm_medium=article&utm_campaign=s3

     
     
    ベンダー中立の評価参謀|atomb.it 基幹刷新・EC・MA選定の評価軸を公開。COBOL〜AI、Shopify内製化、RFP策定、広告運用、RFM/LTV分析まで。製品レビューではなく「失敗しない選び方」を発信。