幅さんのnote記事／noteページはこちら

はじめまして、株式会社カドベヤでエンジニアをしております、幅と申します。
比較的珍しい名字なので世に向かって名乗るのにいくらか抵抗があるのですが、いい加減一人の社会人として名を出して責任を持って発言するということにも慣れていかないといけません
というかよく見たら弊社のwantedly投稿上でも自分の名前が出ているので、この会社に幅という人間が所属していることは既に公開情報となっていました

さて、この度会社からコンテンツを書くようにと指示され1月中に一本目を投稿するということだったのですが早速約束を守れていません
最初は無難に自己紹介でもしようかと思っていたのですが、あまりにもつまらなさそうです
締め切り守れなかった上に内容がひどいと流石にマズいので何かネタがないものかと思案していたところちょうどゼロトラスト回転寿司が話題になっていました

というわけでゼロトラストセキュリティについて回転寿司の例えを挟みながら勉強していこうと思います

つまり本当に締め切りギリギリアウトくらいのタイミングからこの記事を書いているということですね

※自分は普段主にフロントエンドエンジニアをしているのでインフラのセキュリティについては専門外です。間違いがある場合は申し訳ありません。

そもそもゼロトラストとは？

ゼロトラストとは
社内外のネットワーク環境における、従来の「境界」の概念を捨て去り、守るべき情報資産にアクセスするものはすべて信用せずにその安全性を検証することで、情報資産への脅威を防ぐという、セキュリティの新しい考え方。　https://www.nri.com/jp/knowledge/glossary/lst/sa/zero_trust

これだけだとまず「従来の「境界」の概念」ってなんだよとなるかもしれません。ざっくりいうと従来は社内ネットワークと外部インターネットの境界層(DMZ)をファイアウォールなどで強固に防御するかわりに、内部のデバイスについては信用するというようなセキュリティが一般的でしたしかし、近年ではクラウドサービスの普及やリモートワークの増加、そもそものシステムの複雑化など様々な環境の変化がありました

その結果、

• 社外からVPNでアクセスしている端末がマルウェアに感染する
• クラウド上に保管されていた顧客情報が流出してしまう
• ソーシャルエンジニアリングなどにより社内で直接攻撃される
• 一度内部に侵入されるとその中で攻撃が展開されるのを防ぐ手段がない

といった問題が発生するリスクが高まり、従来のセキュリティの考え方では上手くいかないようになってしまいました

回転寿司に来る客は皆寿司が食べたくて来てるんだから余計なことはしないだろうと信頼していたら寿司を食べるのではなく変なことしてtiktokでバズるのが目的の人間が紛れ込んでしまったり、
バイトを雇ってすぐは社員が付きっきりで指導しますが、そのうち慣れてきて任せて社員不在になった途端にテロをされると防げないというわけです

そこで現れたのがゼロトラストという考え方です
トラストがゼロ、つまり誰も信頼できないという性悪説の考え方(誤用)からスタートしてセキュリティ対策を講じていこうという考え方です

これについてNIST（National Institute of Standards and Technology：米国立標準技術研究所）がまとめたレポートであるSP800-207には以下の7つの原則が書かれています

・すべてのデータソースとコンピューティングサービスをリソースとみなす
・ネットワークの場所に関係なく、すべての通信を保護する
・組織のリソースへのアクセスは、セッション単位で付与する
・リソースへのアクセスは、クライアントアイデンティティ、アプリケーション/サービス、リクエストする資産の状態、その他の行動属性や環境属性を含めた動的ポリシーにより決定する
・すべての資産の整合性とセキュリティ動作を監視し、測定する
・すべてのリソースの認証と認可を動的に行い、アクセスが許可される前に厳格に実施する
・資産、ネットワークインフラストラクチャ、通信の状態について可能な限り多くの情報を収集し、セキュリティ態勢の改善に利用する

IST Special Publication 800-207 ゼロトラスト・アーキテクチャ

これらについて一つずつ確認しましょう

すべてのデータソースとコンピューティングサービスをリソースとみなす

アクセスする/されるどちらの側でもネットワークに接続されているすべての機器をリソースとしてみなし、セキュリティ考慮の対象とします

回転寿司のレーンに対して接続しているテーブルや職人などがリソースに該当するでしょう

ネットワークの場所に関係なく、すべての通信を保護する

デバイスが企業内のネットワーク上にあったとしても、それで自動的に信頼して良いというわけではありません

キッチンの内部のバイトによる寿司リソースへのアクセスもそれが本当に適切なものとして承認されるべきなのか検証する必要がありますし、
身内しかいないからと油断して金庫の暗証番号をその情報を知る必要がない従業員にも聞こえるような声で話して伝えてはいけません

組織のリソースへのアクセスは、セッション単位で付与する

従来の考え方では一度行われた認証や認可を保存して次回のリソースへのアクセス時の認証を自動で行うことが多くありましたが、これをやめようという考えです

金庫を開けるのが開店前と閉店後の業務だったとして、例えば通し勤務であったとしても金庫の鍵を本来の保管場所から持ち出し続けて一日働くようなことはせず、利用が終わる度に返却して安全に保管すべきです
魚の仕入れ業者には魚へのアクセス権限を与えるかもしれませんが、魚を搬入するついでに他の食材に触れて移動させるようなことはさせてはいけません

リソースへのアクセスは、クライアントアイデンティティ、アプリケーション/サービス、リクエストする資産の状態、その他の行動属性や環境属性を含めた動的ポリシーにより決定する

従来のようなIDとパスワードだけの認証ではなく、ユーザーアカウントに紐づく関連属性やデバイスの状態・インストールされているソフトウェアのバージョン・ユーザーのこれまでの行動の記録・アクセスしようとする時間帯など、様々な要素を用いて都度決まるポリシーに従ってアクセスへの許可を決めます。

たとえ従業員であっても客として来店しているのなら客として扱い、従業員のみが扱って良いリソースへのアクセスをさせてはいけませんし、
手続きが正当なものであったとしても閉店後本来誰も居ないはずの時間帯に金庫を開けようとするような事があればそれを許可しないようにすべきということです

すべての資産の整合性とセキュリティ動作を監視し、測定する

先にも述べた通り「どのデバイスも本質的に信頼されない」というのがゼロトラストの考え方です。各デバイスがセキュリティを保ち正常に動作しているかどうかを継続的に監視し、状況に応じてアップデートやパッチの適応を求めます
また、脆弱性が見つかったデバイスや管理外のデバイスは正常なデバイスと隔離して扱われるべきです

悪意を持った客によって回っている寿司などに悪戯された場合、すぐそれを検知し、対象の皿を他の客が取ってしまうという事態を防がなければいけません

すべてのリソースの認証と認可を動的に行い、アクセスが許可される前に厳格に実施する

「厳格に」というのはいわゆる多要素認証の使用を推奨するということです
またアクセスするリソース内容やそのユーザーの現在の情報によっては認証済みでも再認証を行うといったフローもあります
その他に、一度認証したとしてもその認証下での行動もまた認証の材料として評価し、場合によってはリアルタイムで評価を更新しましょうという考え方でもあります

寿司屋ではありませんが、クレジットカードの普段とは違う使用記録からカードの不正利用を疑い一時的に停止するといった措置などはこのリアルタイムでの評価の更新と言えるでしょう

資産、ネットワークインフラストラクチャ、通信の状態について可能な限り多くの情報を収集し、セキュリティ態勢の改善に利用する

これはセキュリティそのものではなくそのための情報収集や活用についての考え方です
組織自体の変化、技術の進歩などでネットワークの形態やリソースへのアクセス状況は変化していきます。それに対して新たなポリシーの作成やセキュリティの改善を行わなければいけませんし、そのためにリソースの状態やアクセスログ、ネットワークのトラフィックなどの情報を常に収集・分析する必要があります

おそらくここ最近の事件によってはま寿司とスシロー以外の回転寿司チェーンや外食産業全体が自店舗のセキュリティについて再検討せざるをえないでしょう

以上がゼロトラストセキュリティの7つの原則となります

回転寿司におけるセキュリティリスクとは

さてゼロトラストセキュリティについて理解したところで、実際の回転寿司におけるリスクについて考えてみます
回転寿司における業務フローは色々ありますが、ここでは一般的な「握った寿司を回転レーンに載せ、客はそれを自由に取って食べる」というフローを想定します（個別注文や会計などは考慮しない）

回転寿司におけるリソースは

• 具材（が入っている冷蔵庫）
• 職人
• 各テーブル（と客）

ネットワークは

• 厨房
• 回転レーン

が該当するでしょうか
このうち厨房はどちらかというとプライベート、回転レーンがパブリックなネットワークと見なせそうです

ではこれらのリソースやネットワークにおいてどのような脆弱性・攻撃方法があるのか、一つ一つ考えてみます

具材を起因とする脆弱性

そもそもシャリやネタに問題がある場合が考えられます。仕入れ段階で良くなかったのか管理方法が悪かったのか、いずれにせよこういった具材を気づかずにそのまま提供して食中毒なんて発生した日には一発営業停止でしょう。
これを防ぐためにはまず厨房に立ち入る具材や人物へのチェックと、その具材を使用するできるだけ直前に改めて傷んでないか確認することが大事です。冷蔵庫などの設備が故障していないか定期的に確認する必要もあります
また、信頼している業者からの仕入れであっても、業者が意図していないところで良くない商品を持ち込んでしまう可能性もあります。継続的に監視していくことが何よりです。

ITセキュリティ的に言えばこれはマルウェアをインストールしてしまう場合やマルウェアに感染しているデバイスをネットワーク内に入れてしまうという場合に近いでしょうか
インストールされるソフトウェアのチェックや新たに接続されるデバイスのチェックをするのはセキュリティの基本ですね
ソフトウェアは魚のように腐ったりはしませんが、後から見つかったセキュリティホールを放置しているようなことがあればそれは腐っていると言えるのではないでしょうか？ソフトウェアの情報を収集し、適切にアップデートあるいは他のものに乗り換えていく必要があります

職人を起因とする脆弱性

いわゆるバイトテロなどがここに当てはまりますね。また本人に悪意がなくても疲れていたりチェック体制が甘かったりすることでミスが発生する可能性があります
これを完全に防ぐことは難しいですが、少なくとも何か問題行動をした場合にそれを検出する事ができるような仕組みは必要そうです。単純なのは厨房内を常に録画することでしょうか
また、店長・社員・アルバイトなどの区分に応じて任せて良い・悪い業務が何なのかというルールを事前に明文化したり、職人の習熟度によって新たに任せる業務を増やすなど都度の見直しを行うといったことをするのも良いのではないでしょうか（そのポリシーが守られていることをチェックするというのが難しいですが…）

残念ながらゼロトラストセキュリティでも内部犯による犯行を防止することは出来ません。内部犯だと認証が通ってしまうので何度認証しても無意味です
とはいえ何も出来ることがないのかというとそんなことはなく、認証ではなく認可の部分で適切に権限を与えることでデータへの必要最低限なアクセス以外を制限したり、操作ログを残すことで犯行後の追跡をしやすくするなどはできるでしょう

各テーブルと客を起因とする脆弱性

ここまでの脆弱性は飲食店共通のものでしたが、ここから回転寿司固有の問題も発生してきます（ビュッフェ形式なども近いかも）
回転寿司は回転しているレーン上を流れる寿司を客が取って食べる方式です
ここで問題となるのは、客がレーン上の寿司に対して可能な操作が「取得」だけではないという点です
回っている寿司に対して細工をする、一度取得した寿司をレーンに戻すといった攻撃が容易に行えてしまいます

また、スシローで発生した醤油ペロペロ事件ですが、これは醤油差しを各テーブル上に配置しているから発生した問題ですね
ではそもそもなぜ醤油差しが各テーブルに置いてあるのかというと、醤油が必要になったタイミングで都度店員を呼んでお願いするような形だとオペレーション上のコストが大きすぎるからです。
これを低減するために醤油差しに醤油を補充した状態でテーブルに配置し、定期的に減りを確認・再補充するという方式にしているわけですね（居酒屋やラーメン屋さんなどではよくある方式）
ですがこの方式では醤油差しに何か異常が発生した場合にそれを検知するタイミングが遅くなり被害が拡大してしまうという問題があり、この弱点を突かれたのが先日の炎上です

さて、ITセキュリティでは前者のような攻撃は中間者攻撃（Man-in-the-middle (MITM) 攻撃）、後者はDNSキャッシュポイズニングが近いものと言えるようです
それにしても醤油差しなどの卓上調味料がキャッシュであるという考え方、自分では多分思いつかなかったので見たとき凄いと思いました。

中間者攻撃への対策として基本となるのは通信を暗号化することや、デジタル証明書を用いた署名での改ざん防止などです
暗号化については回転寿司において誰が何を頼んでいるかを秘匿することはそこまで重要ではないので一旦おいておきますが（個別注文で寿司が別レーンなどから直接送られてくるのはVPNに近いですね）、改ざん防止はかなりクリティカルな対策となりそうです
ゼロトラストの考え方的にも、客を過度に信頼して必要最低限以上の権限を付与していることが改ざんに繋がっていると言えるので、ここを制限できるようにするのが対策となるでしょう
例えばですが、くら寿司で使われている寿司カバーをもっと発展させて「カバーを閉じれるのは厨房側の人間のみ可能にする」「レーン上で一度カバーが開けられた場合に見た目としてそれがわかるようにする」といったことが考えられます。
もちろんこれだけだと「全部開けるだけ開けて取らずにスルー」みたいな新たな攻撃が発生するのは想像に難くないので、それを防ぐ新たな対策を講じたり防げなくても検知しやすくなるような仕組みを考えたりが続いていくことになるでしょう

キャッシュポイズニングへの対策ですがDNSキャッシュポイズニングの場合はこちらも電子署名などで不正な応答を検知できるように対策しています
醤油差しの場合はこれを卓上に置く以上攻撃のリスクに晒されるのは避けられないので、検知を早める仕組みや被害の拡大を防ぐ仕組みの構築に注力したほうが良さそうに思えます。前者はカメラでの客席の監視など、後者は醤油差しの補充・点検の間隔を短くするなどが考えられます。
あるいは醤油差しなどの卓上調味料の設置をやめてこれらも全部セキュアに回転レーンを通じて渡すようにするとかでしょうか…？

まとめ

回転寿司屋での炎上行為の事件をきっかけに、ゼロトラストセキュリティについて学びました。
改めて思うのは外食産業、特に安価なお店というのはお客さんへの信頼ありきで成り立っている部分が大きいのだなということと、それが成り立たなくなりつつある現代社会はこれからどうなっていくのかが不安で仕方ないですね
また、今回はゼロトラストの基本的な原則をなぞっていくだけで具体的な実装方法についてはだいぶスルーしたので、今後はそのあたりについて深掘りしていけたらと思っております。

それなりに長い文章になってしまいましたが、ここまで読んでくださり本当にありがとうございます。

おわりに ぼくのかんがえる最強にセキュアなおすしやさん

• 常に責任者となるベテラン職人がいて寿司を握る
• 修行中の弟子は皿洗いなど限られた業務からスタート、寿司を握るなんて以ての外
• 寿司の提供は目の届かないところで邪魔されることが無いように直接持っていく
• 醤油・わさび・食器なども職人が用意して直接お渡し
• 信頼度の高い客のみ受け入れるために紹介制にする

結論：回らない寿司屋が一番