2026年8月28日

「ゼロトラスト」というと、ZTNAやSASEといった技術の話が中心になりがちです。しかし実際に大企業で推進してみると、時間を奪うのは製品選びでも設定作業でもなく、技術では解決しない事柄への対応でした。
本記事では、SIerとしてお客様を支援しながら、自社であるNECグループ全社のゼロトラスト最適化も進めてきた立場から、技術記事や製品カタログにはあまり載っていない“現場のリアル”を3つの教訓としてお伝えします。

目次

教訓1：統一は幻想。決められるのは「標準」だけ

ゼロトラストの中心にあるのは、「ネットワーク上の場所を信頼の根拠にせず、誰が・どの端末で・どのリソースにアクセスするのかを、そのつど判断する」という考え方です。

私自身もNECグループ全社のゼロトラストネットワークの最適化を進めてきました。その入り口が、インターネット向けの通信をすべて個人認証された仕組みに切り替える「認証プロキシ」の導入です。

狙いはシンプルで、通信ログに送信元IPアドレスではなく利用者のIDが記録される状態をつくること。誰が使っているのか分からなければ、「誰に、何を許可するのか」というポリシーはそもそも書けないからです。

すべての通信を認証された状態に統一することを目的とし、施策は開始されました。切り替えの変更作業自体は、設定変更と認証を行うクライアントソフトウェアの配布だけで済みます。

ところがそれで全社の通信をすべて認証に載せられるかというと、そうはいきません。認証とは「人」がいることを前提にした仕組みです。一般的な企業環境では、人を主体としない通信や認証連携が難しいシステムとの接続など、認証通信へそのまま統合できないケースが存在します。
それ以外にもNECグループ内には様々な理由から認証を通せない通信が存在しました。多種多様な機器があり、部門ごとに事情が違う以上、すべてを揃えようとすればどこかで必ず破綻します。

そこで私たちは「統一」を断念し、全社の多数を確実に守れる「標準」を定め、そこから外れるものを例外として切り分ける方針にシフトしました。

様々な環境や事情を整理し、どこに「標準」を置けばなるべく多くの従業員が守られるのかを決めていく。その「標準」は従業員にとって価値のあるものなのかを検討し、深掘りしていく。そして「標準」から外れたものは誰が責任を持つのかまで決めていく。

正直に言えば、この線引きは地味で骨の折れる作業でした。この例外は「標準」に含められないのか、例外側の組織にやり方を変えてもらって「標準」に収められないか——技術的な要素は多くないにもかかわらず、検討と調整の時間だけが確実に過ぎていきます。

それでも、この作業には大きな価値がありました。一度「標準」が定まると、以後の判断はすべて「標準か、例外か」の二択になります。個別の相談が来るたびにゼロから議論する必要はなくなり、例外とするならその条件と期限を決めればよいからです。

判断の基準がないまま個別対応を重ねるほど、組織は動けなくなります。標準を決める作業とは、その都度悩まなくて済む状態を先につくっておく投資でもありました。
すべてを統一できない以上、私たちにできるのは、価値を最大化できる「標準」を可能な限り見極めて定めることでした。

教訓2：例外が増えたら、申請者ではなく「標準」を疑え

前章で述べた「標準から外れるものを例外として認める」という考え方は、そのまま次のテーマにつながります。それが「例外管理」です。

ゼロトラストの理想像は「すべての通信を検証し、統制する」ことですが、前章でも述べた通り現実の企業では、特定サイトへのアクセスや外部ストレージの利用、開発現場でのお客様リポジトリの利用など、どうしても統制外となる例外が発生します。

NECグループでは例外を申請制にして管理する方式を取っています。大規模なお客様でもそうですが、規模が大きくなるほど例外は膨れ上がり、運用負荷増大に繋がります。NECグループでもこの非常に多い例外管理に多くの運用工数が取られていました。

次に携わったのはこの例外の管理運用を改善する施策でした。
施策の過程で例外を一つずつ見ていくと、そこには性質のまったく違うものが混ざっていることに気づきました。判断の分かれ目となったのは、「標準に戻せる条件が定まっているか」でした。

「来年度のシステム更改まで」と答えられるものは、放っておいても終わりが来る一時的な例外です。

一方で、そう答えられないものがあります。サイトの仕様上どうやっても標準に沿えない、業務の形そのものが標準と噛み合わない——そうした、いつまで待っても解消の見込みが立たない例外です。

この二つはまったく性質が違うのに、期限を切って棚卸しするだけの運用では、同じ「例外」として一緒くたに扱われてしまいます。
そして気づいたのは、解消の見込みを示せない例外が並ぶとき、その原因は申請してくる側にあるのではない、ということです。

同じ理由の例外がいくつも挙がってくるのであれば、それは「標準」側が現状を捉えきれていないサインです。その業務を例外扱いのまま個別に管理し続けるより、「標準」そのものを見直したほうが早い。

私たちは例外の一部を「標準」に取り込み、申請数を減らすことで例外管理運用の負荷を大幅に下げることに成功しました。

「標準」に取り込んだ例としては、特定の外部サービスや特定環境へのアクセスのように、多くの利用者が同じ理由で例外申請を繰り返しているケースです。個別申請のまま管理し続けるよりも、利用条件や利用者の範囲を明確に定めたうえで「標準」として扱うほうが、運用負荷を抑えながら統制も維持できます。

もちろん無条件に許容するのではなく、リスクを評価したうえで適切かどうかを判断することが重要です。
例外管理は、「標準」からこぼれたものを片づける後始末の作業だと思われがちですが、実際には次に「標準」をどう直すべきかを教えてくれる、いちばん確かな材料になります。

100%の統一が不可能である以上、例外はなくなりません。だからこそ、例外を「管理された状態」に置くだけでなく、そこから「標準」を育てていく循環をつくれるかどうかが、ゼロトラストを前へ進める分かれ目になると考えています。

教訓3：ゼロトラストへの転換は経営の転換

ゼロトラスト導入がうまくいかないプロジェクトには、共通点があります。それは、セキュリティ部門や情報システム部門“だけ”が頑張っている状態です。

反対に、成功するプロジェクトでは、経営層・事業部門・情報システム部門・セキュリティ部門が同じ方向を向いています。

ゼロトラストは、本来はセキュリティ製品の導入ではなく、働き方やクラウド活用のあり方を変える“企業変革プロジェクト”です。

「標準」をどこに引くかは、どの働き方を全社の前提にするのかという判断であり、例外をどこまで認めるかは、どの業務にどれだけのコストとリスクを引き受けるのかという判断です。いずれも、本来は情報システム部門が単独で決められる範囲を超えています。

ゼロトラストへの転換とは、詰まるところ経営そのものの転換なのだと考えています。
実際、私たちが各施策を何とか進められたのも、それが情報システム部門の一施策ではなく、ゼロトラスト最適化がグループ全体の方針として上位に位置づけられていたからでした。

全社の通信の在り方を変えるという話は、本来どの部門にとっても「今のままで困っていないのに、なぜ変えるのか」という反発を招きかねないものです。

ところが、進むべき方向が経営の方針としてあらかじめ示されていたことで、議論の争点は「やるかどうか」ではなく「どう実現するか」に絞られました。

「標準」の線引きにあれだけ苦労しながらも前に進められたのは、この後ろ盾があったからだと感じています。逆に言えば、上位の方針がないまま情報システム部門だけで同じことを始めていたら、議論は今も終わっていなかったかもしれません。
とはいえ、方針が掲げられれば自動的に進むわけでもありません。

そこで心がけているのが、セキュリティの言葉を経営と事業の言葉に翻訳することです。

「認証を強化します」では現場は動きません。「この投資で業務停止のリスクをどれだけ減らせるのか」「利用者がどのように便利になるのか、また守られるのか」に置き換えて、初めて周囲の理解がついてきます。

裏を返せば、経営層がゼロトラストを自ら関与すべき経営課題として認識した段階から、それまで動かなかった標準や例外の議論は驚くほど早く決まります。

ゼロトラストを情報システム部門の課題から経営の課題へと変えていくこの作業こそが、実は最も価値のある支援なのだと感じています。
そして、この翻訳も一度で終わるものではありませんでした。

クラウドの利用が広がり、働き方が変われば、経営が引き受けるべきリスクも、示すべき方針の中身も変わります。

そのたびに現場で起きていることを経営の言葉に置き換え直し、施策の位置づけを確認し直す。

ゼロトラストにおける経営の転換とは、一度の意思決定ではなく、その時点の正解を確かめ直し続ける営みなのだと考えています。

まとめ

ゼロトラストという言葉には、どこかに“完成形”があるような響きがあります。

しかし現実は違います。

クラウドは増え続け、利用者もデバイスも増え、攻撃の手口も変化し続けます。

ですからゼロトラストは、一度「導入して終わり」になるものではなく、組織や業務に合わせて一歩ずつ前進し、進化し続けるものです。
技術には「正解」があるのに対して、人と組織には「正解」がありません。

設計も設定も、突き詰めれば答えは一点に収束します。

ところが「誰に、どこまで許すのか」「組織としての標準をどこに定めるか」「標準をどうやって変化させていくか」といった問いには、人や組織ごとに異なる事情と利害があり、正しさだけでは決着しません。
だからこそゼロトラストは、製品を入れて終わる仕事ではなく、組織のその時点における正解を追い続ける仕事になります。

統一ではなく「標準」を定めること、例外から「標準」を育てること、それらを経営の課題として捉えること。

ご紹介した3つの教訓は、いずれもこの「正解を追い続ける」一点から生まれたものです。
そして、こうしたつまずきはSIerだからこそ見える景色でもあります。

製品ベンダーは自社製品を、利用企業は自社環境を中心に見ますが、私たちは複数の業界・企業・製品を横断して見ることができます。しかもNEC自身が大規模なインフラを運用する“ユーザー企業”でもあります。

お客様ごとに事情は違っても、つまずく場所は驚くほど似ています。

「この議論は必ず起きます」と最初に共有できることが、合意形成の時間を縮め、手戻りを防ぐ何よりの武器になります。
完璧なゼロトラストを目指して立ち止まるのではなく、現実的な最初の一歩を踏み出すこと。

それこそが、私たちが“ゼロ”番目のクライアントでの実装経験から学んだ、もっとも大切な教訓です。

参考文献

執筆者の他の記事を読む