2025年10月の気になるインターネット記事をピックアップ

9月がまだまだ暑い！とか書いていたのに、10月下旬はもう冬のような寒さです。秋はどこいっちゃんでしょうね？

先月は、ランサムウェアによる被害のニュースが相次ぎましたね。特に、アサヒやアスクルといった、誰もが名前を知っている大企業が業務に支障をきたす事態となり、その深刻さが改めて浮き彫りになりました。

一般のニュースでも「ランサムウェア」という言葉を聞くようになり、これは従業員に対して企業のセキュリティ対策の意識を高める絶好の機会だと考え、この記事を書きました。

こちらも先週公開した、社内の従業員への注意喚起を目的とした記事です。ランサムウェアは、ファイルを暗号化するなど「マルウェア（悪意のあるソフトウェア）が取る行動」の種類を表します。一方で、クリックフィッシングは、利用者をだましてマルウェアを感染させる「手口や手段」を指す言葉です。つまり、クリックフィッシングという手口でランサムウェアに感染させられるケースもあるわけです。

セキュリティ対策は、最も弱い部分から攻撃を受けます。　専門家には既知の情報であっても、「自分は知っているから大丈夫」と軽視してはなりません。

それにしても、私たちが普段よく目にする「私はロボットではありません」のバナーそっくりの偽物を作るなんて、悪意のある攻撃者はどこまで巧妙なのでしょうか。この偽のチェックボックスをクリックすると、マルウェアのダウンロード・インストール命令をクリップボードにコピーするという、非常に悪質な手口です。

パスワードは、特殊文字などの「複雑さ」ではなく「長さ」を求めることを推奨〜NISTがガイドライン更新

NIST（米国国立標準技術研究所）が、パスワード作成に関する最新のガイドラインを更新しました。これにより、これまで私たちが　「常識」としていたことが、実は「非推奨」　となっているため、私たちの知識もアップデートが必要です。

新しいパスワードの考え方

特殊文字や大文字小文字の混在といった「複雑さ」は求めない
複雑なルールを設けても、「password」が「Password1!」のように、推測しやすい形でのパターン化に繋がってしまうからです。
その代わりに「長さ」を推奨
- 多要素認証を導入している場合は8文字程度、そうでない場合は15文字程度の長いパスワードが推奨されています。
「定期的なパスワードの変更」は不要
- 定期的な変更を強制すると、「password1」→「password2」のように、使い回しや少し変えただけの覚えやすいパスワードを設定しがちになります。
「秘密の質問」も非推奨
- ペットの名前などは、推測が容易です（コンピュータを使えばあっという間に試行可能です）。また、本人についてよく知っている人によるなりすましにも悪用されやすいからです。

⚠️ 現実とのギャップ

この新しい常識が広まる中で、私たちが直面している問題は、Webサービスごとにパスワードのルール（文字数、利用可能な文字など）がバラバラであることです。パスワードマネージャで安全なパスワードを生成しようにも、サービスごとにルールを設定しなければなりません。

行政などの公的機関が、パスワードの統一ルールを企業に周知できれば、利用者の負担も大きく軽減されるでしょう。また、セキュリティに携わる企業でさえ、未だにPPAP（パスワード付きzipファイル）を使っていたり、多要素認証に対応していなかったりと、新しいセキュリティの常識に対応できていないことが散見されることも課題です。

Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region

10月20日にAWS（アマゾンウェブサービス）で大きなシステム障害が発生しました。対象は北米リージョンでしたが、Slackなどの海外サービスも影響を受け、その影響の大きさに驚かされた方も多いでしょう。

当社のサービスは東京リージョンを利用していたため直接的な影響はありませんでしたが、AWSのグローバルサービス（Route53やIAMなど）にも影響の可能性が示唆されたため、当時とても心配しました。

その時の障害報告書が公開されましたので、概要を翻訳・要約します。

故障原因：Amazon DynamoDB 原因： DynamoDBの自動DNS管理システムに、「競合状態（レースコンディション）」という一時的に誤作動を起こしやすい状態が潜在していました。この誤作動により、サービスの接続先（リージョンエンドポイント）を示すDNSレコードが誤って空になり、削除されてしまいました。結果として、DynamoDBへの全てのIPアドレスが接続先から即座に消えてしまったのです。

簡単に言うと、DynamoDBの「住所録」に載っていたすべての住所が、誤って一瞬で削除されてしまったような状態です。驚くべきことに、この住所録には顧客のサービスだけでなく、AWSの内部サービスが利用している接続情報も含まれていたため、障害が広範囲に及ぶ原因となりました。

故障の連鎖：Amazon EC2 原因： EC2インスタンスを管理するAWS内部のシステム　「Droplet Workflow Manager (DWFM)」　が、DynamoDBに依存していました。 DynamoDBが使えなくなったことで、DWFMはサーバーの状態チェックを完了できなくなり、サーバーの利用権（リース）が時間切れ（タイムアウト）になりました。影響：新しいEC2インスタンスを起動しようとしても、「容量不足」や「リクエスト制限超過」といったエラーで失敗する事態となりました。

私たちユーザーが複数のAWSサービスを組み合わせてシステムを作るのと同じように、AWS自身も内部でAWSのサービスを組み合わせてシステム（この場合はDWFM）を構築していることが分かります。

特にus-east-1はAWSが最初にサービスを始めたリージョンであり、グローバルサービスの一部は実質的にこのリージョンに依存しているため、障害の影響が大きくなりました。

もはやAWSは、私たちのビジネスに欠かせません。自前でシステムを組むよりもはるかに高品質で安定したサービスを提供してくれていることに感謝しつつ、今後も障害が起きないことを願うばかりです。

経済産業省が検討するセキュリティ対策評価制度を分かりやすく解説

2026年10月以降の運用開始が予定されている「サプライチェーン強化に向けたセキュリティ対策評価制度」が、いよいよ動き出しそうです。経済産業省の公式サイト

なぜこの制度が必要なのか？

経済産業省によると、近年は「サプライチェーン（供給網）」を狙ったサイバー攻撃が増えています。

現状の課題：

大企業が自社のセキュリティを固めても、業務委託先など取引先（サプライヤー）のセキュリティが脆弱だと、そこを経由して情報漏洩が発生し、委託元の企業にも大きな被害が及びます。
取引先企業から、セキュリティ対策の状況についてバラバラのチェックシートの記入を求められ、対応に多大な労力がかかっています。

制度の目的：こうした非効率を解消し、セキュリティ対策の基準を統一すること。

✨ 制度がもたらすメリット

この制度は、取引先がどのような対策を、どのレベルまで行っているかを第三者（評価機関）が統一ルールで認定・評価するものです。

評価の明確化：従来のISMS/ISO 27001のような「対応している or していない」という抽象的な評価ではなく、「★3です」「★4です」といった具体的な数値でレベルを評価できるメリットがあります。
業務の軽減と本質的な強化：各社バラバラのチェックシートへの記入作業が軽減され、その分の工数を、より本質的なセキュリティの強化施策に充てられるようになるでしょう。

この制度は、私たち企業のセキュリティ担当者にとって、非常に期待の大きい取り組みです。