2025年11月の気になるインターネット記事をピックアップ
気が付けば11月も終わり。本当は有給を取ってセキュリティのセミナーに参加したかったのですが、仕事が忙しくて叶いませんでした。 そんな中、気になったセキュリティ関連のニュースを紹介します。
生成AIガイドラインとは？企業に役立つひな型を公開！リスクや対策も解説
企業が生成AIツールを導入するためには、専用の「社内向け 生成AIガイドライン」を整備することが欠かせません。生成AIにおけるリテラシーには個人差があり、各従業員の判断に任せた運用となれば、生成AIに起因するセキュリティ事故や著作権侵害などのリスクが予期されるためです。
先月のSoftware DesignでもAIのセキュリティについて特集されていました。AIがこれだけ利用される現代、セキュリティを考えるのは当然です。 むしろコーポレートサイトに「私の会社はこういうルールで生成AIを利用しています」と、プライバシーポリシーと同じように載せるべきだとも言われています。
従業員に対してはペラ1枚でもよいので、以下の周知が必要です。
- 使用可能な生成AIツール
- 入力禁止の内容について
- 生成AIの見解を会社の見解として掲載しないこと（AIに「その根拠となるWebサイトを教えて」と伝え、人間が必ずチェックする）
- 生成AIの成果物掲載の際、著作権を侵害していないことを法務に確認すること
これはつまり、法務部門も生成AIについて無関係ではいられない、ということです。最近、Webサイト画面の右下にチャットAIが表示され、いろいろと質問に答えてくれる便利なサイトが増えています。しかし、AIが明らかに荒唐無稽なウソをついたとしても、それは掲載している企業の責任となり、金銭的ダメージとなるケースも実例として存在します。 AIの安易な利用に対しては、セキュリティの観点からも責任者がチェックするべきです。
企業からのデータ流出ルートは「ウェブブラウザでのコピペ」が最多
今年の情報処理安全確保支援士のオンライン研修でも 「セキュリティ担当は組織内のAIの活用を推進し」「同時にセキュリティの懸念点の解消に努めるべき」 とありました。 つまり「ウェブブラウザ上で動作するチャットAIを利用するな」は非推奨の行動であり、先ほど述べたようなガイドラインの作成と周知、そして可能であればガイドラインを守っていない人を検知する対応が必要となります。
2025年11月18日のCloudflareの障害
11月18日、X（旧Twitter）が急に動作しなくなったことで有名になったCloudflareの障害。私の会社でもCloudflare上で稼働させているサイトに繋がらなくなり困りました。なにせドメインの向き先を変えようとしても、コンソールにログインできないためDNSにすら繋がらなかったのですから、打つ手がありませんでした。
世間の知名度はそれほどでもないかもしれませんが、Cloudflareは今最も勢いのある会社の一つ。便利で安価なサービスを多数提供しています。私もこのブログとは別のブログをCloudflare Pagesにホスティングしていますし（当然当時はアクセスできませんでした）、月10GBまで無料のオブジェクトストレージR2を利用しています。
多くの会社が、まさかCloudflareがこの規模の障害を起こすとは想像していなかったのではないでしょうか。Xだけでなく、ZennやクラスメソッドのブログDeveloper’s I/Oも閲覧に影響が出ており、あらゆるところでCloudflareのサービスが使われていたことを再認識しました。 私自身も慢心があり、AWSやGCPのステータス監視はしていたものの、Cloudflareのサービスステータスは監視していませんでした。今回を機に、ステータスに異常が認められた場合にすぐ通知されるよう仕組みを構築します。Route53で死活監視するのが良いと思います。
ランサムウェアの拡散を防止し、ファイルを容易に復元する、Google ドライブの新 AI 機能を発表
先月発生したアサヒグループやアスクルに対するランサムウェア被害により、現場は普段使える便利ツールが利用できず、不便や非効率を強いられているとのことです。先月の記事でも紹介したように、ランサムウェアはもはや社会現象であり、企業だろうが個人だろうが他人事ではありません。
ファイアウォール型のセキュリティに加え、ゼロトラストが普及するようになった背景も、もはや「侵入されない」ことを前提とした従来の境界防御では現代の脅威には太刀打ちできず、「侵入は必ずいつか起こるもの」という前提に立ち、いかにビジネスへの影響を最小化し、迅速に復旧するかに焦点を当てた「サイバー・レジリエンス（回復力）」の重要性が高まっているからだと考えます。
Google Workspace の文書（Google ドキュメントやスプレッドシートなど）はランサムウェアの影響を受けず ※ 、また ChromeOS もこれまで一度もランサムウェア攻撃を受けたことがありません。しかし、PDF や Microsoft Office などの他のファイル形式や、Microsoft Windows のようなデスクトップ OS は、依然として脅威の標的となります。＜中略＞パソコン版 Google ドライブに搭載された AI による検知機能は、ランサムウェアがファイルを一斉に暗号化または破壊しようとする兆候を特定します。そして、ランサムウェアが拡散する前にクラウドへのファイル同期を停止することで、ユーザーのファイルを迅速に保護します
※ Google Workspaceネイティブのファイルについてはそもそも圧縮（暗号化）ができないため
ローカルのファイルがクラウドに自動で同期する機能は便利ですが、ローカルファイルが暗号化されてしまった場合、リモートのファイルも暗号化されてしまった、という悲劇を事前に食い止めるAIを導入したとのことです。加えて、ローカルの暗号化されてしまったファイルを、クラウド側の正常なファイルで復元する機能も提供されます。 また、仮にGoogleドライブ内のファイルが暗号化されてしまっても、Googleドライブ内のファイルをある程度の時点まで復元する機能について、個人利用の無料ユーザ含め利用可能になることは非常にありがたいです。
この機能はランサムウェアのすべての課題を解消するわけではありません。現在主流となっている「二重脅迫」（データを暗号化したうえで、盗み出したデータをネットに暴露すると脅すやりかた）の後者は防ぐことができません。そもそも最近は暗号化すらせずに、データを盗んだうえで暴露をネタに金を要求する「ノーランサム」という手法も増加しています。 とはいえ、私たちのデータをGoogleが守ってくれるこの機能、デフォルトではONになっていますし、ありがたく活用しましょう。
AWS CLIの 新機能 aws login コマンドを試してみた
ローカルPCからAWSを操作する場合、IAMユーザのアクセスキーをローカルに格納し手利用する方法が一般的でしたが、これはアクセスキーが漏洩するセキュリティリスクから定期的にローテーションすることが求められる一方でローテーションが面倒だというジレンマがありました。それを解消する新機能がリリースされたということで、記事にあるようにやってみました。
aws cliがこのPCにはインストールされていなかったので、インストール後aws loginを実行。初回なのでデフォルトで利用するリージョンを設定
ブラウザで認証画面が表示されます。ここでログインユーザにルートユーザ化、IAMユーザを選択します。通常はIAMユーザを使うでしょう。
認証に成功します。これでローカルでAWS CLIが利用できるようになります。
これだけでは記事の内容とまったく変わらないので価値がありませんｗ ですので、自分なりに気が付いたことを補足しますと、この作業のを行うと、ローカルの.aws/login/cache/フォルダ配下にjsonが作られます。 このjsonファイルに従来credentialsファイルに記載したアクセスキー、シークレットアクセスキーが記載されています。つまりこれが漏洩するとヤバいのですが、この情報にはexpiresAtが設定されており、ある程度時間が経つとアクセスキー情報は失効します。おそらく自動ローテーションもaws cli内でやってくれるのでしょうね。 今後は従業員が利用しているIAMユーザにアクセスキーを付与するのではなく、こちらを利用してもらうほうが安全で管理も楽になります。
アサヒGHD サイバー攻撃で個人情報191万件漏えいの恐れ 勝木社長らが会見【ノーカット】
サイバー攻撃による業務への支障は当然経営へ大きなダメージが出るということで、CEOのみならずCFOも会見で状況を説明することとなりました。サイバー攻撃は上場企業にとっても他人事ではない、そして2か月経った今も影響が出てしまっていることなど、経営層はセキュリティについて考えざるを得ない時代です。 しかし、テレビのニュースでも「RaaS（Ransomware as a Service：犯罪組織にランサムウェアを提供し、犯罪組織が実行する）」という言葉が出るのは意外でした。
障害が起こるずっと前から潜伏し、権限情報の窃取と他のサーバに対しての侵入を粛々と行っていたのですね。9月29日の朝までに完璧に仕込まれて、一気に暗号化＆窃取したと。テキストではお約束の “MITRE ATT&CKの14の戦術（Tactics）” ですが、実際にやられると恐ろしいです。CEOは言葉を濁していますが、やはりVPNから侵入されてしまったようです。VPNがアタックサーフェイスとして危険なのはみんな分かっているのですが、VPNを使わない業務は不可能です。 工場の生産システムに影響は出ていないものの、出荷に使っているシステムが使えなくなってしまったため、Excelや紙・FAXを使った手作業で対応しているとのこと。効率は悪いですし、現場の人は大変です。 ただ今回の記者会見でCEOが 「健康を害してまで対応をしなくてよいと社員には言っている」 と回答したことは、社員にとっては救いですよね。記者会見でたびたびCEOが従業員を労っていたのが印象的でした。
以下は質疑応答の中で、セキュリティに関する質問と回答を列挙しました。当然ながら言えないことが多い一方で、「想像している通りです」という回答から、おおよその原因が見えてきます。。「VPNの脆弱性を最新に保つ、それだけ」という人もいるかもしれませんが、その工数すら捻出できない現実があるのもまた事実なのです。セキュリティにもっとヒト・モノ・カネを投下しなければいけません。
質疑応答のまとめ
Q. 封じ込めに時間がかかった理由 A. ネットワークを利用しつつ、被害が拡大しないように作業を進める必要があったため、専門家の知見を借りて慎重に行った。システムを使った受発注は時間がかかったができるようになった。
Q. 情報開示の姿勢、情報開示のタイミングは適切だったのか A. 具体的な内容を詳細に公開すると、攻撃者を利することになる（他の企業についても迷惑がかかる）。情報漏洩については本当に漏洩したのかを慎重に点検していた。
Q. ランサムウェア攻撃者に対して身代金は払ったのか A. 攻撃者に対しては連絡が取れていないので払っていない。
Q. データセンターのパスワードが盗まれたということだが、パスワードはどのように管理されていたのか A. 詳細なことは答えられないが、脆弱なことは間違いない。
（筆者注：passwordなんてパスワードになっているはずはないし、複雑なパスワードにしても、大量のパスワードリストを流されると、結局多要素認証やIPアドレス制限をしないとだめなんだろうなぁ）
Q. 十分なサイバーセキュリティ対策を施しているのか A. NISTのサイバーセキュリティフレームワークを用いて、一定レベル以上の成熟度を持っていると考えていた。ホワイトハッカーによる模擬攻撃を実施し、課題の解消を行っていた。しかし今回の攻撃は高度・巧妙な攻撃だった。安全性を高めるということに限界はない。 より高度なセキュリティ体制、検知ができるようにしたい。
Q. 影響を受けている端末の台数は？ A. DCのサーバに対する攻撃がメイン、合計37台が影響を受けている。
Q. 復旧の方法は？フォレンジックで安全が確認されていたサーバは利用するのか？ A. バックアップがあることが幸いしてこれを使って復旧するが、そのまますぐ復旧するのではなく、調べてから復旧させた。
Q. 侵入経路はVPN装置ということでよいのか？ Fortinetだったのか？ A. 侵入経路は明かせないが、VPNは廃止した。
Q. BCPについて詳しく聞きたい A. 手作業でやれたことは良かったと思うが、これだけ時間がかかっていることは良いとは思っていない。もっと早く復旧するよう改善をしていきたい。ゼロトラストセキュリティに対しては移行中だった。ゼロトラストに移行するにあたり、BCPでいかに早く復旧するかについては前倒しで検討を進めていきたい。業界間での協力もしていきたい。
Q. 攻撃に対する精度を向上するとのことだが、10日前に検知できていなかったのか、これを検知するにはどうするつもりか A. 不正なアクセスがあった場合検知するEDRを導入していたが、攻撃者の手段が巧妙かつ高度だったため、検知できなかった。EDRのレベルを上げたい。外部の力を借りて高度なものを構築したい。
Q. 攻撃者からの接触は無かったということだが、仮に接触があった場合、どのようなシナリオを想定していたのか。攻撃者側の目的はうかがい知ることはできるのか？ A. 接触ないから分からないが、目的は金銭目的だったと思う。
Q. ランサムウェア対策にバックアップが大切というが、さらにどういうことができる余地があるか A. 戦略までは至っていないが、複数の場所に分散して配置するとか。
Q. 従業員の貸与しているPCには個人情報は含まれていたか？ A. 従業員のローカルPCに個人情報を入れることをポリシーとして認めていないが、一時的にローカルに保存している情報が盗まれた可能性がある。ただし、極めて重要な個人情報ではなかったという認識。
Q. クラウドはゼロトラストを導入していたが、オンプレミスはゼロトラストが間に合っていなかったということ？ A. 結果としてはできていなかった。
Q. 複数媒体にバックアップなどの対策は取っていたのか？ A. 詳細は言えないが、当然複数媒体にバックアップを取っていたため、復旧につなげることができた。
Q. システム復旧にかかった費用の規模感 A. 今は分からない。
Q. 2か月の復旧（長期化）した理由 A. システムが複雑だった。社内、社外に一つずつ説明して、封じ込めして、データを移して、などの作業を慎重に行った結果時間がかかった。
Q. 再発防止策について。VPNは廃止し、従業員に教育を行ったというが、体制を万全に行った、という目途は？ A. 完了という状況になるのかは分からない。具体的な対策については詳細は申し上げられない、それを言うと突かれてしまうので。
Q. なぜアサヒビールだったのかという思い、攻撃者に対するメッセージ A. まったく思い浮かばない。腹立たしいという思い。
Q. 今回のセキュリティ被害について、経営者として他の会社に還元したい思いはあるか A. 全体を広く見よう、対策を頑張っていこう。結果として我々は対策が最強でなかった、完璧ではなかったことが分かった。
Q. システムやDXに対しては評価が変わった気持ちはあるか？ A. 経営者はこれからもっと大変になる、知見を高めガバナンスに活かさないといけない、すべてにおいて気を配り、対策していかないといけないのだなと思った。
Q. 今後の教訓のためにも、ある程度の段階になったら、攻撃手段がこういう手段だった、と公開することはあるのか A. 今の時点では言えないが、今後検討したい。
Q. 企業にとってセキュリティ対策の決意を教えて A. エンタープライズリスクマネジメントにおいて、AIを用いたサイバー攻撃にも想定していたが、攻撃された。
Q. VPNが原因だったのか？この脆弱性は既知なのか、ゼロデイだったのか？ A. 侵入口については申し上げられないが、ご想像と違わないのではないか。既知の脆弱性だったと考えている。
Q. バックアップの細分化と言っていたが、バックアップがあったが一筋縄では戻せない、ということがあったのでは？バックアップを使って復旧した際の上手くいかなかったこととか？ A. 瞬時には戻せない。戻しても同じことが起こる。疎結合でシステムを作っていたことが幸いした。疎結合のサーバをきれいさっぱり一から作って再構築したものもある。