電話番号通知と偽装の技術

Pre Script

Deep Research優秀すぎるよね。例えば特殊詐欺の発信番号通知が警察署になっている件に関して、発信者番号通知の仕組みや偽装方法について調査して貰ったのがこのレポート。

「電話回線における発信者番号通知の仕組みやプロトコルについて、電気的な部分の仕様について教えてください。またどのようにすれば発信者番号を偽装し、任意の発信者電話番号を付与する事が出来るか考察してください。」みたいな雑なプロンプトでも、ものの10分程度で情報を纏めてくれる。

ざっと確認したところ、概ねあってそうなのでそのまま公開。

1. はじめに

発信者番号通知(Caller ID)は、電話の着信時に発信者の電話番号を受信側の電話機器に表示するサービスであり、現代の電話通信において不可欠な機能の一つです。技術的には発信者の電話番号のみを提供しますが、一般的には発信者名表示(CNAM: Calling Name Presentation)と合わせて利用されることが多く、受信者が着信に応答するかどうかを判断する上で重要な情報源となっています 。特にビジネスの現場においては、発信者名を適切に表示することが、顧客からの信頼を得て応答率を高める上で非常に重要です 。発信者番号通知サービスは、アナログ電話回線だけでなく、デジタル電話システムや VoIP(Voice over IP)など、幅広い電話システムで利用されています 。  

本レポートでは、電話回線における発信者番号通知の基本的な仕組みから、関連するプロトコル、電気的な仕様について詳細に解説します。さらに、近年社会問題となっている発信者番号の偽装(Spoofing)について、その技術的な背景、具体的な手法、およびそれによって生じるリスクと悪用例を考察します。最後に、発信者番号偽装に対する技術的な対策、法規制の動向、そして利用者が自身を守るための対策について議論し、今後の展望について考察します。本稿は、発信者番号通知技術に関心を持つ技術者や研究者、そしてそのセキュリティに関心を持つ読者を対象としています。

2. 電話回線における発信者番号通知の仕組み

2.1 電気的な仕様

アナログ電話回線における音声信号は、連続的な電気信号として伝送されます。これに対し、発信者番号通知の情報は、通話が確立する前に、音声伝送とは異なる方法で送信されます 。この情報伝送には、FSK(Frequency Shift Keying:周波数偏移変調)という変調方式が一般的に用いられています 。特に北米地域では、Bell 202 規格に基づく 1200 ボーのモデム技術と同一の FSK 技術が採用されています 。Bell 202 規格では、論理的な「1」は 1200 Hz のトーンで、「0」は 2200 Hz のトーンで表現されます 。一方、ヨーロッパ地域では、CCITT V.23 規格も使用されています 。  

発信者番号通知情報の伝送速度は、一般的に 1200 ボーです 。Bell 202 の検出信号範囲は、-48 dBm から -43 dBm 程度であり 、送信機の負荷インピーダンスは 600 オームとされています 。また、オフフック時の信号レベルは、-30.78 dBm から -7.78 dBm の範囲内です 。MT88E39 チップのような特定の集積回路は、3 V から 5 V ±10% の電源電圧で動作することが可能です 。これらの電気的仕様は、発信者番号通知システムを適切に設計・運用するために重要な要素となります。  

2.2 プロトコル

発信者番号通知サービスは、国際電気通信連合(ITU-T)の勧告 Q.731.3 で最初に定義されました 。地域によって異なる規格が存在し、北米では Bellcore(現 Telcordia Technologies)の規格が広く採用されています 。ヨーロッパでは ETSI EN 300 659-1 規格が定義されており、V.23 モード 2(リング後 FSK)、V.23 モード 2(リング前 FSK)、DTMF シグナリングが含まれます 。英国では SIN227 規格が使用され、V.23 FSK とライン反転が特徴です 。オーストラリアは Bellcore FSK 規格を使用し 、中国の 1997 年の規格は Bellcore 規格と類似しています 。  

米国とカナダでは、発信者番号通知のメッセージ形式として、発信者の電話番号、日付、時刻のみを送信する SDMF(Single Data Message Format)と、これらの情報に加えて発信者の名前も送信する MDMF(Multiple Data Message Format)の 2 種類が用いられます 。SDMF は発信者の電話番号(DN: Directory Number)を最大 10 桁まで含むことができます 。一方、MDMF は SDMF の情報に加えて、最大 15 ASCII 文字の発信者名を含むことができ、DN は最大 15 桁まで可能です 。MDMF を読み取れる機器は SDMF も解釈できますが、SDMF 専用の機器は MDMF を認識できません 。  

Caller ID のデータパケットは、プレアンブル、メッセージタイプ、メッセージ長、実際のデータ、そしてチェックサムで構成されています 。SDMF 形式のパケットでは、2 バイトのヘッダー(メッセージタイプと長さ)がデータパケットの先頭に付加されます 。MDMF 形式のパケットも同様にメッセージタイプと長さから始まり、その後にパラメータタイプ、パラメータ長、そして実際のデータブロックが続きます 。プレアンブルとして、受信側のタイミング同期を助けるために、交互の 1 と 0 のシーケンスと、180 個の連続する 1 が送信されます 。データの各バイトには、開始を示すスタートビット(0)と終了を示すストップビット(1)が付加されます 。チェックサムは、メッセージタイプからチェックサムの直前のバイトまでの全てのデータバイトのモジュロ 256 和の 2 の補数として計算されます 。  

表 1: 発信者番号通知メッセージ形式

形式説明含まれる主要情報
SDMF (Single Data Message Format)発信者の電話番号、日付、時刻を送信する形式電話番号(最大 10 桁)、日付、時刻
MDMF (Multiple Data Message Format)発信者の電話番号、日付、時刻に加え、名前も送信する形式電話番号(最大 15 桁)、名前(最大 15 ASCII 文字)、日付、時刻

表 2: 主要な発信者番号通知規格(地域別)

地域/国使用規格主な特徴
北米(米国、カナダ)Bellcore FSK1200 ボー、SDMF/MDMF
ヨーロッパETSI EN 300 659-1V.23 モード 2(リング後/前 FSK)、DTMF シグナリング
英国SIN227V.23 FSK、ライン反転
オーストラリアBellcore FSK1200 ボー
中国規格(1997年)Bellcore 規格と類似

2.3 伝送タイミング

発信者番号通知の情報は、一般的に電話の最初の呼び出し音(リング)と 2 番目の呼び出し音の間の無音期間に送信されます 。一部のシステムでは、最初の呼び出し音が鳴る前にデータが送信されることもあります 。通話が最初のリングの後、あまりにも早く応答された場合、発信者番号通知の情報が受信側の機器に正しく送信されない可能性があります 。  

具体的なタイミングシーケンスとしては、最初の呼び出し音の終了後、通常 500 ミリ秒から 2000 ミリ秒の間に FSK 変調されたデータの送信が開始されます 。そして、2 番目の呼び出し音は、この FSK 変調データの送信が終了した後、最低でも 200 ミリ秒後に開始されるように規定されています 。ただし、リング信号の持続時間や、最初のリング終了からデータ送信開始までの時間、データ送信終了から 2 番目のリング開始までの時間には、ネットワークや機器によって変動があり得ます。受信側の機器は、これらのタイミングの変動を許容し、正しく発信者番号を検出できるように設計されている必要があります 。  

2.4 CNAM (Calling Name Presentation)

発信者名は、技術的には CNAM(Calling Name)と呼ばれるサービスによって提供されます 。発信者名は、発信側のセントラルオフィスから送信される場合と、着信側の交換機がライン情報データベースを検索して取得する場合があります 。カナダの一部のシステムでは、CCS7(Common Channel Signaling System No. 7)と呼ばれる共通線信号方式を使用して、通話設定情報とともに発信者名が自動的に送信されることがあります 。  

着信側の電話会社は、受信した電話番号(CLID: Caller ID Number)をもとに、CNAM データベースを検索し、対応する名前を取得して受信側の電話機に表示します 。この CNAM データベースは、電話会社によって異なる場合があり、統一された中央データベースが存在しないため、発信者名を更新した場合、その情報が全てのデータベースに反映されるまでに時間がかかることがあります 。また、一部の携帯電話事業者は、独自の Caller ID 名前サービスを提供しており、加入者が追加のサービスに加入しない限り、CNAM 値の表示を制限する場合があります 。  

CNAM で表示できる名前には、最大 15 文字の ASCII 文字という制限があります 。一般的な表示名は 9 文字から 12 文字程度です 。CNAM の値として許可されるのは、英数字とスペースのみであり、アポストロフィ、ハッシュタグ、カンマ、ピリオドなどの特殊文字は使用できません 。また、CNAM は常に大文字で表示されるという特徴があります 。  

3. 発信者番号の偽装

3.1 偽装が可能となる理由

発信者番号の偽装(Caller ID Spoofing)が可能となる主な理由は、発信者側が受信側に通知する電話番号を制御できる仕組みにあります 。固定電話の場合、通常は回線に登録されている電話番号が表示されますが、PRI(Primary Rate Interface)や SIP(Session Initiation Protocol)といった接続方式を利用する場合、電話システムは通話ごとに表示する番号を柔軟に制御できます 。特に VoIP(Voice over IP)サービスにおいては、アナログ回線とは異なり、発信者名だけでなく、表示する電話番号も容易に変更することが可能です 。一部の VoIP プロバイダーは、Web インターフェースを通じてこれらの情報を直接設定できる機能を提供しています 。このように、発信者番号(CLID: Caller ID Number)が発信者によって設定可能であるという点が、従来から第三者の発信者 ID を詐称することを容易にしてきました 。  

従来の POTS(Plain Old Telephone Service)回線においては、ネットワークは電話が応答されるまで発信者を着信者に接続しないため、通常、発信者が Caller ID 信号を直接変更することはできません 。しかし、PBX(Private Branch Exchange:構内交換機)の背後からの発信では、より多くのオプションが利用可能です 。一方、VoIP 技術はインターネットを利用して通話を行うため、従来の電話回線をバイパスし、発信者番号の偽装に対して特に脆弱であると言えます 。  

3.2 偽装の具体的な手法

発信者番号を偽装する具体的な手法としては、主に以下のものが挙げられます。

VoIP (Voice over IP) サービスを利用した偽装: VoIP を利用することで、比較的低コストかつ容易に発信者番号を偽装することが可能です 。Asterisk や FreeSWITCH などのオープンソースソフトウェアを利用することもできます 。一部の VoIP プロバイダーは、ユーザーが Web インターフェース上で表示する番号を直接設定できる機能を提供しています 。特に、卸売 VoIP プロバイダーは、そのサービスを再販する事業者がエンドユーザーの電話番号を正しく表示できるように、通常、任意の発信者番号の送信を許可しています 。  

PRI (Primary Rate Interface) 回線を利用した偽装: PRI 回線も、Caller ID の偽装によく使用される方法の一つです 。  

スプーフィングサービスとソフトウェア: プリペイドの通話カードと同様の仕組みで動作するスプーフィングサービスが存在します。ユーザーは事前にサービス料金を支払い、PIN(Personal Identification Number)を取得します。その後、指定された番号に電話をかけ、PIN、宛先の電話番号、そして表示したい Caller ID を入力することで、発信者番号を偽装することができます 。多くのスプーフィングサービスプロバイダーは、Web ベースのインターフェースやモバイルアプリケーションを提供しており、ユーザーはアカウントを作成してログインし、偽装する発信元の電話番号、宛先の電話番号、そして表示したい偽の発信者 ID 情報を入力することができます。サービス側のサーバーは、これらの情報に基づいて、指定された発信元と宛先の両方に電話をかけ、それらをブリッジ接続することで、受信側には偽の Caller ID が表示される仕組みです 。一部のサービスでは、通話の録音、声の変更、テキストメッセージの送信などの追加機能も提供されています 。SpoofTel、Spoof My Phone、My Phone Robot、Spoofcard、BluffMyCall など、様々なスプーフィングサービスが存在します 。また、Vonage、OnSip、Google Voice など、一部の通信事業者やサービスプロバイダーも、意図せずまたは特定の目的のために、発信者番号の変更機能を提供している場合があります 。  

その他の手法(オレンジボクシングなど): オレンジボクシングと呼ばれる手法は、より高度な技術を用いた偽装方法です。これは、ソフトウェアを使用して Bell 202 FSK 信号をエミュレートし、通話中にその音声信号を電話回線に送り込むことで、実際には着信がないにもかかわらず、受信側の電話機に偽の発信者番号を表示させるものです 。この手法は、技術的なハッキングという側面よりも、受信者を欺くためのソーシャルエンジニアリングの要素が強いとされています 。  

表 3: 一般的な発信者番号偽装手法

手法説明主な特徴
VoIP スプーフィングVoIP サービスを利用して発信者番号を偽装低コスト、容易に実行可能、Web インターフェースで設定可能な場合あり
PRI スプーフィングPRI 回線を利用して発信者番号を偽装法執行機関や企業などで利用される高度な接続
スプーフィングサービスプリペイド式またはアカウントベースで利用可能なサービスWeb サイトやアプリを通じて操作、通話録音などの機能がある場合も
オレンジボクシングBell 202 FSK 信号をエミュレートするソフトウェアを使用技術的な知識が必要、ソーシャルエンジニアリングの要素も含む

3.3 偽装によるリスクと悪用例

発信者番号の偽装は、様々なリスクを引き起こし、不正な目的のために悪用される可能性があります 。主な悪用例としては、以下のようなものが挙げられます。  

詐欺: 詐欺師は、銀行、クレジットカード会社、政府機関、警察などを装い、被害者から個人情報(口座番号、クレジットカード情報、社会保障番号など)や金銭を騙し取ろうとします 。  

なりすまし: 知人、友人、家族などを装って電話をかけ、緊急の事態を装って金銭を要求したり、個人情報を聞き出したりする手口があります 。  

嫌がらせ: 特定の個人や組織に対して、無言電話や脅迫的な内容の電話を繰り返し行う嫌がらせ行為に利用されることがあります。

ネイバースプーフィング: これは、被害者の電話番号と最初の数桁が同じ番号を偽装して電話をかける手口です。これにより、被害者は近隣からの電話であると錯覚し、応答しやすくなるため、詐欺などの成功率を高める効果があります 。  

企業への悪用: 競合他社や悪意のある第三者が、正規の企業を装って顧客に誤った情報を提供したり、信用を失墜させたりする目的で発信者番号を偽装するケースも考えられます 。また、存在しない罰金を科したり、業務停止を強要したりする事例も報告されています 。  

4. 発信者番号偽装への対策と今後の展望

4.1 技術的な対策

発信者番号偽装への対策として、技術的な取り組みが進められています。その代表的なものが、STIR/SHAKEN 認証プロトコルです。STIR(Secure Telephone Identity Revisited)と SHAKEN(Signature-based Handling of Asserted Information using toKENs)は、IP ネットワークにおける発信者 ID を認証し、偽装された通話を識別するためのフレームワークです 。STIR/SHAKEN は、発信側のサービスプロバイダーと着信側のサービスプロバイダーが協力して、通話の発信元と電話番号の正当性を検証する仕組みです 。この認証により、受信者は表示された発信者 ID の信頼性を高め、詐欺電話や迷惑電話を回避することが期待されます 。米国連邦通信委員会(FCC)は、すべての音声サービスプロバイダーに対し、2021 年 6 月までに STIR/SHAKEN を実装することを義務付けました 。しかし、STIR/SHAKEN は、IP ベースのシステムを介して送信される通話には有効であるものの、レガシーネットワークや国際電話にはまだ課題が残されています 。また、STIR/SHAKEN は完全に偽装を阻止するわけではありませんが、不正な発信元の追跡を容易にし、悪意のある業者の参入障壁を高める効果が期待されています 。  

不正な発信者番号の検出とブロックも、重要な対策の一つです。多くの携帯電話事業者やサードパーティのアプリが、迷惑電話や詐欺の可能性のある電話を自動的にブロックまたは警告する機能を提供しています 。FCC は、電話会社が合理的な分析に基づいて迷惑電話をデフォルトでブロックすることを許可しており、これにより、利用者が迷惑電話に悩まされる機会を減らすことが期待されます 。  

4.2 法規制の動向

発信者番号偽装に対する法規制の動きも活発化しています。米国では、Truth in Caller ID Act が、詐欺、危害、不正な利益を得る意図を持って誤解を招くまたは不正確な Caller ID 情報の送信を禁止しており、違反者には 1 回につき最大 10,000 ドルの罰金が科せられます 。2019 年には、この法律が国際電話とテキストメッセージにも拡張されました 。同年には、TRACED Act(Telephone Robocall Abuse Criminal Enforcement and Deterrence Act)が成立し、Caller ID 認証が義務付けられました 。  

国際的な取り組みとしては、カナダでは発信者番号の偽装は現時点では合法ですが、CRTC(カナダラジオテレビ通信委員会)は STIR/SHAKEN のような CID 認証システムの導入に取り組んでいます 。インド政府は、発信者番号偽装サービスを提供する Web サイトのブロックや、報告された事例の調査を通信事業者に指示するなどの措置を講じており、偽装された通話サービスの利用はインド電信法の下で違法とされています 。英国では、ダイレクトマーケティング会社は 2016 年以降、電話番号を表示する義務があり、違反者には罰金が科せられる可能性があります。英国の電話ネットワークは 2025 年までに VoIP に更新される予定であり、これにより発信者番号偽装に対処するための新しい対策が可能になると期待されています 。  

4.3 利用者側の対策

発信者番号偽装による被害を防ぐためには、利用者自身も対策を講じることが重要です。まず、不明な番号からの電話には注意し、安易に応答しないことが推奨されます 。応答してしまった場合でも、個人情報や機密情報の提供は絶対に避けるべきです 。緊急性を装ったり、脅迫的な言葉を使ったりする電話は特に警戒が必要です 。もし相手が企業や公的機関の職員を名乗った場合でも、相手から伝えられた電話番号に折り返し電話をするのではなく、公式な連絡先(アカウント明細書、電話帳、Web サイトなど)を使用して、その電話が正当なものであるかどうかを確認することが重要です 。  

個人情報の保護も、偽装による被害を防ぐ上で重要です。オンラインでの個人情報の共有を控え、ソーシャルメディアなどのプライバシー設定を見直すことが推奨されます 。不要なオンラインコンテストや懸賞には注意が必要です 。また、データブローカーからの個人情報削除を検討することも、迷惑電話や偽装電話を減らす上で有効な手段となります 。  

5. 結論

本レポートでは、電話回線における発信者番号通知の仕組み、電気的な仕様、プロトコルについて詳細に解説しました。発信者番号の偽装が可能となる理由とその具体的な手法、偽装によるリスクと悪用例についても考察しました。最後に、発信者番号偽装への対策として、技術的な取り組みである STIR/SHAKEN 認証プロトコルや不正な発信者番号の検出とブロック、法規制の動向、そして利用者側の対策について議論しました。

今後の展望としては、STIR/SHAKEN などの認証技術のさらなる普及と高度化により、発信者番号偽装がより困難になることが期待されます。また、国際的な連携による法規制の強化も、グローバルな課題である発信者番号偽装への対策として重要です。そして、利用者一人ひとりが発信者番号偽装の手口を理解し、適切な対策を講じることで、その被害を最小限に抑えることが期待されます。技術開発、法規制、そして利用者の意識向上の三つの側面からの取り組みが、より安全で信頼性の高い電話通信環境の実現に繋がるでしょう。

「情報流通プラットフォーム対処法」に思うところ

「情報流通プラットフォーム対処法」が話題になっている。案の定だけど誤って削除した場合の対処について一切言及が無い。取り締まろうとすれば、当然のことながら虚偽の申請や誤った判断によって削除される例は必ず出てくる。

現在のSNSアカウントは広告収入を生み、あるいは事業宣伝の重要なプラットフォームであり、誤って削除された場合には名誉だけでは無く経済的な不利益も発生する。削除を容易にするのであれば、それと同時に誤って削除された場合の回復も容易にしなければ全体のバランスをとれなくなる。

例えば誤って削除された場合に、それによって発生した損害は誰がどのような形で賠償すると考えて居るのだろうか?削除の判断を下した事業者か?削除を申請した利用者か?法律を運用する総務省だろうか?

手続きを簡易化すること自体には賛成だが、過って削除した場合の扱いをおざなりのまま、事業者の責任で削除を実施するなら、いまのまま都度裁判所に申請して対処する方がマシだろう。

本来こういったコンテンツ規制を行うなら、削除基準が正しく運用されているか確認する第三者機関が必要だ。それが総務省になってしまっている事も問題だと思う。本来なら天下り団体と揶揄されようと中立的な第三者機関を作るか、国民が直接監視する仕組みを設けるべきであったと思う。

https://www.soumu.go.jp/menu_news/s-news/01ryutsu02_02000426.html

某高校の入試申請で話題になってたメールサーバーのこととか

神奈川県の高校入試出願システムで障害、志願者のGmailにメール届かず – 現在は解消

神奈川県下の中学三年生は約7万3千人。予備のメールアカウントも登録しているから、全員に一度にメールを送信しようとすると、約15万通のメールを一度に送信しうるメールサーバーという話になる。

件のメールサーバーではMXテーブルにIPアドレスを指定していたことが原因で、SPFやDKIMが機能していない。その状態で大量のメールを送信したためレピュテーション(評価)が低下、不正中継サーバーと判断されて、メールを拒否されるようになった。Googleが制限しているためメールを受信出来ないという表現は確かにその通りだが、不正メール対策として正しく設定していないメールサーバーからのメールを受信しないのはGoogleに限らず多くのベンダーで行っている基本的な対策だ。正しく設定出来ていなかったメールサーバー側が全面的に悪い。

では正しく設定出来ていたら問題無くメールを送れたかというと、実は送信出来なくなった可能性が高い。新規にドメインを取得して間もなかったり、普段より極端に多くのメールを送信した場合にも、レピュテーション(評価)が低下する。これはSPFやDKIMによる認証が行われるようになる以前から行われていた不正中継対策だ。

もし独自にメールサーバーを立てるなら、ユーザーの利用が集中しないように利用開始時期を分散させつつ、レピュテーション(評価)の状態を確認しながらメールの送信数を調整、時間当たりに送信するメールを少しづつ増やしていく必要がある。運用に常に人を張り付けて微調整が必要になる。そもそも1~2月だけ大量のメールを配信するというのはレピュテーション(評価)を下げやすいので、年間通してメールを送り続けるような仕組みまで考えておく事を求められる。

実際には上記のような運用は手間がかかるし、バッドノウハウの塊なので経験がないものが実施するのは難しい。そこで通常は大量のメール送信を代行する、メール配信事業者に頼むことになる。

1月~3月だけ数十万通のメールを送信するシステムで、自前のメールサーバーから配信しようとしている時点で、発注者側にも受注者側にも適切に設計を出来るIT知識が無かったことがうかがわれる話だったりする。

参考:Google メール送信者のガイドライン

MNPで携帯電話を乗っ取りSMS認証を突破される

さっきまで使えてたスマホ、通話音が…しない 勝手に解約されたかも 被害男性の証言

偽造運転免許証をもちいて携帯電話のMNPを申込みんで携帯電話を乗っ取り、オンラインバンクのSMS認証を突破されてしまうという問題が多数発生しているらしい。記事の中でも「パスワードを使い回さないなど、やはり個人の対策が重要だ」と書かれているとおり、一番の問題はパスワードを適切に管理出来て居なかった事にある。

SMSを使用した多要素認証は、NIST(米国立標準技術研究所)でも条件付き推奨としている。推奨するための条件は、「他の認証方式と併用すること」「代替の認証方法を用意すること」「危険性の評価し公表すること」三つだ。SMSは電話会社での管理が適切である事を前提としており、技術的あるいは社会的方法で容易に突破されうる事が分かっているからだ。

SMSは攻撃に弱い認証方法であるという前提を理解して、正しくパスワードによる認証を使う事が大事です。「サービス毎に異なるパスワードを使う」「パスワードはランダムな文字列にする」「前述二つを実施するのはパスワード管理ツール無しでは無理なので、適当なツールを利用する」の三点をしっかりまもろう。

そしてエンジニアもSMS認証は弱いと言う事をちゃんと認識してサービスを設計しよう。

PPAP問題はパスワードをメールで送るのを止めても解決しない

PPAP(パスワード付きZIPファイルと、そのパスワードを別送する)が無意味どころか、むしろ危険を増している事がようやく認識されるにいたった。だが、もう一つの問題、そもそもZIP2.0暗号方式を使って暗号化することの無意味さが知れ渡っていないようだ。

ZIP2.0暗号方式には計算量的脆弱性があり、比較的少ない計算量で総当たり攻撃をおこなえることが知られています。ハイエンドGPU(RTX 2080Ti 価格20万円程度)を4枚搭載したパソコンを使用すれば、15桁のパスワードでも15時間程度で解読できてしまう事が報告されています。ということは文字数を増やして16文字にすれば56日となるかというと、これ以上パスワードの文字数を増やしても解読に変わる時間は延びません。内部的に96bit(15文字程度)の状態しか持てないため、これ以上パスワードを長くしても意味が無いのです。

ZIP形式のファイルはこの問題を解決するために、今ではAES方式暗号に対応しています。ですが、Windowsが標準ではAES方式のZIPファイルに対応していないために、利便性を優先してZIP2.0を使用する事が常態化しています。セキュリティは利便性とのトレードオフになる事が度々ありますが、利便性を優先して実効性のない暗号方式を採用し、そのために無駄な作業や別の危険を増やすのは本末転倒でしょう。

暗号化したファイルのパスワードをメール以外・・・例えば電話で伝えるのは進歩です。でもZIP2.0形式を使い続けるなら、そこに実効性はありません。利便性と実効性を考えたなら、素直に暗号化などせずに添付して送るのが一番良いでしょう。

ではどうすれば良いのでしょうか?私がお勧めするのはメールを使用しない事です。メールの根本的なセキュリティ問題は認証機能が無い事にあります。そこで認証機能のしっかりしているSNSなり、Google Drive等のストレージサービスなりを経由して送るわけです。この時使用するサービスは、出来ればデータを受け取る側に用意して貰うことが重要です。アップロードする場所を指定するやりとりの中で、重要なデータを送る前に相互に認証を行う事ができます。

セキュリティ上、メールサーバーはどんなサービスを利用すべきか。

業務上使用しているメールサーバーのセキュリティについて考慮したことがあるだろうか?実態として問題なく利用できるメールサービスは限られている。

セキュリティ上、パスワード漏洩等のインシデント発生時に被害の程度や範囲を特定する必要がある。このためには最低限でもPOP/IMAP/SMTP/WebMailの認証ログを閲覧し不正な接続の有無や接続元を特定する必要がある。だが実態として認証ログを閲覧出来る事が明記されているメールサービスは少ない。

サービスを提供する事業者は第三者間の電気通信を中継している都合、電気通信事業者とてし法律の制約を受ける。そこには通信の秘密を守る義務が含まれており、通信相手の接続元などの情報を提供することが出来ないためだ。

自社でメールサーバーを運用するのであれば、電気通信事業法上の制約を受けることなくログを閲覧出来る。かといってメールサーバーの運用には多くのノウハウがあり、中小企業でメールサーバーを運用できる技術者を確保する事は難しい。

以下にセキュリティ上の認証ログを閲覧出来るメールサービスを例示しておく。色々と探したのだが、三つしか見つけることが出来なかった。

Google Workspace
Microsoft 365
カゴヤ・ジャパン株式会社 メール専用サーバ

番外として下記も紹介しておく。認証ログを閲覧する事は出来ないが、代わりに接続元IPアドレスを制限する事が出来る。境界型セキュリティで安全を担保する前提であれば、接続元IPアドレスを制限したり、代理サーバーを介在させたりすることで、同様の要件を満たす事はできる。
WebArenaメールホスティング

Excelのパスワードを解除する方法

Excelのパスワードを解除する裏技を求めて、当WEBに来る方が少なくない。 「ブックの保護を強制的に解除する」は保護をすることで安全に隠せている気になっている記事への警告の意味で書いたので、パスワードが分からなくて困っている人へと補足情報を載せておこうと思う。

避けては通れない法律的な話し

まず法律的なことを覚えておいて欲しい。

何らかの方法でパスワードを調べたり、調べたパスワードを保管したりする行為は「不正アクセス行為の禁止等に関する法律」に抵触し、刑事罰の対象となる。例えファイルの中味を閲覧しなかったとしても、パスワードを調べたり、保管しているだけで処罰の対象となる。

裏技などを使ってパスワード(技術的利用制限手段)を迂回したりする行為は「著作権法」に抵触し、これまた刑事罰の対象となる。 著作権侵害の多くは親告罪だが、技術的利用制限手段の回避は非親告罪となる。

また裏技をつかってパスワード (技術的利用制限手段) を迂回するためのツールを提供する行為は「不正競争防止法」に抵触する。平成30年からはツールを提供するだけではなく、依頼を受けて役務を提供する事も処罰の対象となる。

以上のような法律があるので、いくら探しても「パスワードを解除して欲しい」という依頼を受けてくれる人は見つからない。Excelのファイルを解析してパスワードを解除するようなツールも見つからない。仮に技術的かつ予算的に可能であっても、家族や親友からの依頼でも無い限り、リスクが大きすぎて受けられないのだ。

とはいえ、パスワードが分からなくて途方に暮れている様もよく分かる。解決方法はただひとつしかない。技術的な知識と、法律的な知識を自ら身につけ、自らの手で作業するしかないのだ。

裏技による迂回方法

ブックやシートの保護パスワードや、VBAのソースコード閲覧パスワードなどは裏技的な方法で解除できる。実際に解除する方法は「Excel の各種パスワードを突破する方法まとめ」に良くまとまっている。新たに追記することはしない。

読み取りパスワードの解除

読み取りパスワードだけは総当たりで解除するしかない。だが、辞書に載っているような単語だけであるとか、あるいは6~7文字程度のパスワードであれば、解除できなくもない。

パスワードの解析によく使われるのは「John the Ripper password cracker」と言うツールだ。

私の使っている20万程度のパソコンでもGPUを使うと3,000パスフレーズ/秒程度のスピードで解析を進めてくれる。英数だけで構成される5文字程度のパスワードなら、最悪でも60時間程度で解析が終わる計算になる。辞書に載っているような単語、十万語程度を対象とするならば、数分で終わってしまう。

最高スペックのGPUを使うなら1桁程度は早くなる。IaaSで高速なサーバを複数台レンタルするなら2桁程度は早くなる 。6文字程度のパスワードなら総当たりでも 数日程度で 割り出すことが出来るし、そのために発生する費用は10万円にもみたない。

Postscript #1

そんな分けだからパスワードの分からなくなったファイルのことはキッパリと諦めて、ファイルをゼロから作り直すことを第一選択肢として考えたほうが良い。

Postscript #2

いまどき7文字程度のパスワードしか設定していないのは、実効性が無いので止めておいたほうが良い。無駄な仕事を増やしているだけに過ぎない。

DELLのセキュリティー事件簿

元記事:実態調査が示すセキュリティー事故の最新動向

DELLのもうちょっと良い事例は無かったのだろうか?
インシデント(セキュリティー事故)が発生するのは仕方ないにしても、あまりにも稚拙な対策が混じっていて失笑を禁じ得ない。

CASE1、CASE2・倫理観低下が招いた事故

論理感等という曖昧なものに原因を求めてはならない。分からない言語のメールだからそれを無視したり、業務効率向上の為のチャットソフト利用を拒絶する事が、論理感の高い行動とは言わないだろう。

根本的な原因は、恐らくはリスクのある外部サービス利用に対する過度な制限や、外部サービス利用承認プロセスの不備、ネットワーク利用状況の監視体制の不備にあると推測する。下手な利用制限がかかっていなければメジャーな翻訳サイトを避けて稚拙な翻訳サイトを使ったり、適切な監視がなされていればチャットソフトの利用に気がつかないと言うことはないからだ。

制限、許可、監視のバランスがとれていないことが根本の原因にあるなかで、制限だけを増やすのは問題の解決には至らない。制限を回避する新たな方法を編み出すようになり、従業員との信頼関係が損なわれる結果が目に見える。

CASE3・CASE4・ランサムウェアに感染

そもそもバックアップを取れていないことが致命的に問題だ。バックアップがとれていればデータが失われても1日分程度の話しであり、データを失うと言う致命的事態には陥らない。バックアップは一般ユーザーの権限ではアクセス出来ない(最低限で書き込めない)場所に、過去4~5日分(気がついたときには上書きされていたら意味が無いので、夏期休業などの最長休業期間より長い日数分)をバックアップしていれば良い。

標的型メールを模倣する訓練において開封率の低下を目指すことに意味は無い。本来なら開封した場合のエスカレーションが確実に行われることや、開封によって感染したことをセキュリティ監視チームが発見できる事が重要になる。なぜなら100人中1人でも開封すれば被害に繋がるし、またどんなに訓練を重ねたところで、文面などから完璧に不正なメールを判断するのは不可能に近いからだ。

CASE6・CASE7・基本的な対策を怠った

CASE6のすべてのPCのOSを最新に するのは確かに必要な処置だろう。だが起こった問題「商談情報を撮影して個人のPCにメールで送ったりしていた」に対する対策としては「機密情報の撮影を禁止」と言うルールを設けただけである。いかにルールを作っても、ルールが守られていることを監視監督する等の運用面が苫なわなければ、仕事のためにルールを無視する事が必ず起こる。

CASE6の根本的な原因は、メールの送信先や送信元に対する監視が機能していない事にある。個人で取得していると思われるメールに対する送信だけでも監視していたなら、問題が発生する前に警告する事が出来たはずだ。

CASE7についてはログが無い以上、今後調査が進展する可能性もない。「漏洩した情報を特定できない」という報告をする以外にない。

セキュリティ上、クラウドサービスを業務に使ってはならないとき・・・

「オンプレミスに比較して、クラウドはセキュリティが心配・・・」と言うユーザーに対して「クラウドベンダーと御社とどっちのセキュリティが上だと思ってるの?」というのは昔から良く話しとして見かける。実はクラウドサービスのセキュリティで気をつけるべき視点がひとつある。インシデント発生時に速やかな対応が可能か否かだ。

一流のクラウドベンダーならユーザー側に起因するインシデント発生時の対応も考慮されている。だが、二流三流のクラウドベンダーとなるとかなり怪しい。ユーザー側の原因でインシデントが発生した時に、影響範囲特定に必要なログ等の提供を受けられない可能性がかなり高い。例えば以下のシナリオのような状況が考えられる。

インシデントシナリオ#1
自社のWEBサービスがSQLインジェクション攻撃を受けた。この場合は影響範囲の調査にデータベースサーバの監査ログが重要な役割を果たす。もしこの時、ベンダーの提供するデータベースが他のユーザー企業とインスタンスを共有している場合、監査ログには他のユーザー企業の発行するSQL文まで含まれてしまう。ベンダー企業が監査ログをユーザー企業ごとに分割するような対策を事前に取ってない限り、迅速な対応は期待できない。

インシデントシナリオ#2
メールアカウントのユーザーIDとパスワードが漏洩して第三者が閲覧した可能性がある。この場合にはメールサーバーの認証ログを閲覧して、不自然なな時間帯や接続元からの認証、認証エラーの有無を確認したい。もしこの時、ベンダーの提供するデータベースが他のユーザー企業とインスタンスを共有している場合、そこには他のユーザー企業のログも含まれている。さらには通信事業者には通信の秘密を守る義務が課せられている。通信時間帯や接続元IPアドレスは通信の秘密に含まれるため、頑なに開示してもらえない可能性がある。こうなると被害届をだして事件化しないと、影響範囲の特定も出来なくなってしまう。

無論、きちんとしたベンダーは回答を用意している。AWS AuroraDBやSQL Azureには監査ログの機能がある。オブジェクトストレージのS3はアクセスログを提供している。GSuiteやOffice365も認証ログを提供している。

対して国内ベンダーに目を向けると、大手ベンダーでもその辺りがかなり弱い。

例えばさくらインターネットがS3互換としているオブジェクトストレージにはアクセスログの機能が無い。

あるいはNTT Communicationのメールホスティングサービスにはメールの送信ログに対する検索機能はあるが、認証ログの提供はない。法的な問題もあるので提供が難しいのは分かるが、せめて認証成功のログ程度はないとインシデント発生時に対応出来ない。

ベンダーの多くは電気通信事業者として「通信の秘密」に関する義務をおっている。何時何処と通信をおこなったかは「通信の秘密」に含まれるため、電気通信事業者としては安易にログを開示する事は出来ない。ユーザー企業に公開できるのは、ユーザー企業の管理下にあるシステムのログだけになるが、事前に準備を整えていない限り共有部分のログ提供には時間がかかる。

クラウドサービスを採用するにあたっては、セキュリティ監査に耐えるだけのログ出力機能があるか否かは確認した方が良い。もしそれらのログ出力機能が無く、インシデント発生時に相応の対応が必要なら、契約に調査対応への協力義務を盛り込む程度のことは検討しなてくはならない。

※クラウドベンダーの対応状況は2019年9月時点のもの

不要になったホームページの閉鎖のしかた

不要になったホームページを閉鎖する手順を記した良記事。
ドメイントラブルを防ぐ、Webサイトを正しく閉鎖する方法

一時期にはキャンペーンサイトなど安易に期間限定でドメインを取得してしまうWEBサイトが多数あったが、最近は問題点が知れ渡ったのか大分減ってきた。取得してしまったドメインを方々に迷惑を掛けることなく、キチンと止めるのはとても面倒なのである。

まとめるとこんな感じ。
1.閉鎖したドメインで一定期間は閉鎖の案内を表示するか、あるいは新URLへの転送を行う。
2.HTTPリファラーをモニタリングして、可能な限りリンク元URLに対して変更依頼を行う。
3.閉鎖するドメインへのアクセスがほぼ無くなったのを確認した後にWEBサーバーを廃止。
4.WEBサーバ廃止後はDNSからレコードを削除。
5.WEBサイトを閉鎖した後もドメインは更新し続け手放さないのが理想。