どうも、柚人です。
note久しぶりに書きます。
いろいろとニュースになっているのでご存知の人もいるかとおもいますが、この記事は以下の問題に関するお話です。
専門家や一般向けというよりは、普段このあたりに関わりのないIT技術者の方などに、と自分の勉強のために書いています。
一部専門家の方から見れば「おかしい」というところがあるかもしれませんが、まだまだ勉強中の身なので、その点ご了承ください。

はじめに

自分自身はこの件の被害者ではないですが、情シスとして会社のドメインの設定情報などドメイン管理者と一緒になりながら対応しているので、ちゃんと対応していなければこうなっていたのでは・・・と、非常に学びを得ています。

「システムの問題」というと領域が大きいのでもう少し言葉を絞ると、この問題は「ドメイン」の信頼性と「DNS（Domain Name System）」の設定によって起きた「メールのセキュリティ領域における知識の欠如」が原因で起きたような事象と認識しています。
ちなみにこの問題は以下のようにカナガクさんやAWSの鈴木さんが色々纏めてくれているので、時系列やトラブルシューティング的な部分は割愛したいと思います。

まずは結論から

この記事は専門的な部分も含み長くなるので、結論から述べておきます

• DNSはしっかり理解して、そして必ず設定しよう

  • MX、SPF、DKIM、DMARC、ドメインの関係性、信頼度の理解

• セキュリティ技術の一環なので、被害事例をしっかり調べよう

  • なりすまし

  • ドメインハイジャック

  • タイポスクワッティング

• サブドメインの役割を理解してドメインを分けよう

• ユーザー側の環境を模して、ログから検証しよう

今回の問題では

• 新規取得のドメインばかりだった

• ドメインが事後に取得された

  • 事故発生が1/9、ドメイン取得が1/12

• MXレコードが複数設定されている

  • AmazonSESを使っているがMXにAmazonSES用のMXレコード以外にAmazonEC2のインスタンス3つが登録されていた

• DMARCの設定が厳しい

  • 最初は（ドメインの信頼度がないので）p=noneにしなくてはいけないのに、p=quarantine（迷惑メールフォルダに振り分け）になっていた

• 受信者（利用者）側にホワイトリスト登録を努力させた

など、様々な観点で問題がありました。
教育委員会が外注した結果起きた事例でもありますが、こういった「発注側の、納品されたものに対する品質確認ができていない話」はよくある話で、発注者責任を満たすに足らない状況が「IT人材が不足している」と言われる一端かと思います。
発注元・発注先にドメイン/メール関連に一定レベルの技術者がいれば障害が起きることはなく、ユーザー環境を模して検証していれば猶更防げた事例だと思っています。

出てくる用語と関係性

まずは一般的な部分として用語の説明をしておきましょう。
今回はメールのお話なので、郵便局と封筒に例えた説明を多く入れています。

IPアドレスとドメイン、そしてDNS

IPアドレスは例えば自宅のネットワークとかだと192.168.1.xといったXXX.XXX.XXX.XXXの255.255.255.255を最大値とするインターネット上でいう郵便番号のようなものです。
例えば日本だと3桁-4桁の計7桁ですが、他の国にも同じようにその地域を表す番号があります。
ドメインはこのnoteだとnote.com、というURLを示します。
メールではxxx@note.comというアドレスだった場合、@以降を示します。
ドメインですが、インターネット上でnote.comは1つしか存在しません。
また、サブドメインというものがあり、例えばnoteは編集中editor.note.comというURLになります。
note.comの大きなドメインの中にeditorという用途別のドメインを作っているわけで、これはnote.comのドメインを操作できる人にしか作ることはできません。
DNSはドメインネームシステム、ドメイン名を定義するシステムです。
note.comというドメインは18.172.52.34というIPアドレスです、と教えてくれるのがDNSの役割です。
郵便番号100-0001と言えば東京都千代田区千代田、と郵便番号台帳みたいなもの、とイメージすればわかりやすいかと思います。
ドメインは今回のように.jpのアドレスであれば　JPRS WHOIS /JPRS　から取得状況や持ち主を確認することができます。

RFCとMX、SPF、DKIM、DMARC、ARCとヘッダーFrom、エンベロープFrom

メールについては主な国際規格としてRFCが存在します。
身の回りのもので言えばJIS規格やISO規格のインターネット版とでも思ってください。
これに準拠していないものは正規品でないとして混在させないのも技術者や販売者の役割です。
はがきがすべて同じサイズで作られているのは、大量にやりとりされるメールが、ちゃんとしたものか一括で機械的に振り分ける目的でもあります。
メールサーバーは、送信元メールサーバー・受信元メールサーバーがありますが、郵便局をイメージすると分かりやすいです。

そしてDNSに設定する値として以下のレコードがあります。
MX：Mail Exchange、メールシステムを使う上で必ず必要になります。複数レコードが設定される場合、優先順位をつける必要がありますが、1つのみの方が事故が起きにくくなります。
SPF：Sender Policy Framework、DNSに送信元がどこかを確認させる目的です。送信元署名や消印みたいなものですね。
ただ、SPFがDNSに確認するのは次に説明するエンベロープFromですがヘッダーFromに設定してしまって届かない、といったケースもあるようです。
また、複数行を受け付けず、10個以上書かれていると、DNS参照が失敗することもあります。
ヘッダーFromとエンベロープFrom：メールにはFromアドレスとして2種類のアドレスが含まれます。
例えば封筒に書かれている住所や会社名は委託業者で、中身は自分が契約しているサービスの運営会社の封筒が届いた場合、封筒に書かれているのはエンベロープFromで、中の書面に書かれているのはヘッダーFromです。
DKIM：Domainkeys Identified Mail、簡単に言えばヘッダーFromとエンベロープFromの信頼関係が正しいものであることを宣言するものです。
セレクタ名._domainkey.ドメイン名という書き方をされます。
DMARC：ドメインを使って送られたメールのSPF/DKIM検証結果で、どうするかというルールです。
なりすましメールが送られていても、通常なりすましをされた側は気づくことができません。
DMARCを設定しておくと、なりすましメールを代理で破棄してくれたり、「これもしかすると迷惑メールかもしれないので注意してください」と迷惑メールフォルダに振り分けてくれたり、配送結果を指定のアドレスに返してくれる「自動通報窓口」といった役割をします。
ARC：例えばメール（郵便物）を転送した場合、上記のなりすまし検証情報は引き継ぐことが出来ませんがARCに対応しているとそれらを再度認証し直してくれます。

これらを詳しく規格引用も含めて書かれたページを見つけたので、詳しく知りたい方はこちらをご覧ください。

なりすましと法律

少なからず、amazon.co.jpになりすました「アカウントが停止されました」といったようなメールを受け取った、またはそういう迷惑メールが飛んでいることを聞いた、ということはあるかと思います。
Webページでも同様の偽装はありますが、メールでは表示名をAmazonサポート<abcdefg@gmail.com>といった名前を語ったり、Amazonサポート<support@annazon.co.jp>と見間違えるようなメールアドレスになっていることもあります。
また、スマホだと表示が"Amazonサポート<sup…"と表示が切れて居たりするので、送信者が正しいかがどうかがぱっと見わかりません。
そういった詐欺送信者を罰する、発生させない目的として特定電子メール法、通称「特電法」という法律が存在します。
そこでは上記の設定に加え、配信の解除リンクや虚偽送信など、インターネットメール環境の汚染を防止する内容が書かれています。

Gmailの送信者ガイドライン強化と関係性

今回の問題は冒頭にも書いた通り、設定ミスが主な原因でしょう。
そのため、1/19に発表された神奈川県教育委員会の謝罪会見において、それらが全く触れられず、「登録が集中したため」「Gmailの問題」と原因究明、対応と責任範囲がぐちゃぐちゃで、TLでも多くの「いやそれは違うだろ」という意見をいくつか見ました。
今回の事例で問題のあった点は、Googleが昨年から発信しており、2023/12にようやく対象が個人ユーザー向けである「@gmail.com」宛に絞られた以下のガイドラインでも注意が促されています。
なお、このガイドラインで言われる1日あたり5000件以上、というのは「なりすましも含む、ヘッダーFromが対象のドメインになっているもの」なので、正規の送信者だけでないことも注意点の一つです。
なお、この制限は2024年2月以降、と書かれているので、現時点では有効になっていない可能性が高く、単純に冒頭の結論で述べていたドメイン設定ミスに尽きるかと思います。
特にDMARCのパラメータのうちp=については、none（何もしない）、quarantine（迷惑メールフォルダに振り分ける）、reject（削除する）を受信側メールサーバーに指示するものであり、rua=という集計結果レポート送付先に送られる値でドメインの安全性が高くなってから徐々にnone>quarantineと厳しくしていく必要があります。

これは個人的な観点からの推測ですが、Gmail側がこのあたりを厳しくした背景に
・なりすましが増える一方
・それに伴い、脆弱性を疑われ、Gmail、ひいてはGoogleの製品がセキュリティが弱いと思われかねない
・より健全性を高めるため、セキュリティ対策は必須の風潮
があるかと思います。

たとえば「〇〇ひかり」といった通常の回線事業者ではないチラシが家のポストに投函されていたことがある方も多いでしょう。
ああいった「悪意のある詐欺事業者」が投函したのか、郵便局が発注を受けて投函したのかは、受け取るだけの我々一般人には関係ありません。
多くの場合「そういうのが投函されてしまった」ことに対して不信感を抱きます。
その不信感を相手に抱かせない為、厳しく中身を検閲したりするのはサービス提供者側です。
郵便物に置き換えてしまえば、郵便局（Googleのメールサーバー）が、より「一般住民に届ける郵便物に対しては、虚偽の発送センターからは預かりません。預かっても破棄します。」と宣言したに過ぎず、Google側は当たり前のことをしたまでです。

ホワイトハッカーの存在とドメインの脅威

ドメイン名におけるローマ字表記の危うさ

今回は対象とするユーザーが「中学生、またはその子を持つ親」になっています。
つまり、ITリテラシーが高いユーザーではありません。
また、今回県教育委員会が3つのドメインをホワイトリストに登録するよう、案内を出しました。
これら問題が起きたドメインは攻撃者の格好の的です。
設定が不十分だったことが明白にばれている＝サービスに対するセキュリティ技術者のレベルが低い、と推測が容易ですから。
そして、長いドメイン名やローマ字表記は間違いを誘発しやすいです。
ローマ字にはヘボン式・日本式・訓令式とパターンがあります。
今回shutsugan-kanagawa.jp、shutugankanagawa.jp、nyushi-kanagawa.jpを登録してくれ、と教育委員会は案内しています。
出願、とローマ字で書いたり、タイピングする際にみなさんは「shutsugan」と書きますか？「syutsugan」と書きますか？
shuはヘボン式で、syuは訓令式です。
タイピングにおいてはいずれでも「しゅ」が出るので、yを使う人もそこそこいるのではないでしょうか。
そのため、「syutsugan-kanagawa.jp」と打ってしまう人もでてくるでしょう。

タイポスクワッティング

syutsugan-kanagawa.jpを攻撃者、ハッカーが取得し、誤って入力してしまったら、ユーザーはそことやりとりを始めます。
出願サイトですから、個人情報なども入力されます。
そういった方法をタイポスクワッティング（タイポ＝入力ミス、スクワッティング＝居座り）と言いますが、誤ったサイトへの誘導だけでなく、正しいサービス元が悪用されないためにそのドメインを買い取ることもあります。
その際に不当に高い価格で売りつける、という目的もあります。

今回、syutsugan-kanagawa.jpというドメインがXServer株式会社という、ドメインを提供する会社を連絡先とする人物に取得されています。
これはドメイン提供会社のホワイトハッカーが「希望があれば譲りますよ、それまでは悪用されないよう、保持しておきますね」という意思表示でもあります。
なんともありがたい話ですよね。
なお、正規のサービス元ドメインである「nyuushi-kanagawa.jp」については「nyushi-kanagawa.jp」というドメインがだれか別人によって取得されていますが、こちらはお名前.comというドメイン提供サービスで取得されただけで、正規の神奈川県教育委員会または委託会社が取得したかは不明ですが、委託元である場合はshutsugan-kanagawa.jpやshutugankanagawa.jpと情報が同じになるはずなので、外部の人間であることが推測されます。

ドメインハイジャック

また、神奈川県教育委員会は、結局shutsugan-kanagawa.jpとshutsugankanagawa.jp、nyuushikanagawa.jpを今後今回開発した出願申請サービスが終了してもドメインを維持しなくてはなりません。
神奈川県教育委員会がこれらのドメインをサービス終了と共に破棄した場合、攻撃者によって乗っ取りが発生し、ドメインが悪用される、という「ドメインハイジャック」の対象になるためです。
ましてや対象が前述の通り中学生やその家庭ですから、余計に危ういですよね。

トップレベルドメインの違い

ドメインにはトップレベルドメイン、2nd、3rdとあります。
例えばpref.kanagawa.jpであれば
トップレベル＝jp
2ndレベル＝kanagawa
3rdレベル＝pref
ですが、例えば今回のようにshutsugan-kanagawa.jpだとshutsugan-kanagawa.orgやshutsugan-kanagawa.com、shutsugan-kanagawa.net
といってトップレベルを替えれば取得できてしまいます。
これらを踏まえて、なりすましを防ぐにはしっかりと押さえておくのも一つの方法です。

まとめ

GmailやHotmail、Yahooメールなど、一般ユーザーにはメールアドレスが取得しやすい環境になりました。
また、今回AmazonSESやAmazonEC2が使われたように、クラウドサービスも多数使われるようになり、より手軽にシステム構築が可能になりました。
スマホも1人1台、しかも今の10代は子供のころから触れている正にデジタルネイティブの世代です。
同様に、攻撃者（ハッカー）も物量で勝てるように攻撃方法の共有がサブスク化されたりなど、様々な進歩を遂げています。
本当に目まぐるしく環境が変わっていきます。
また、IT技術も人が作ったものなので、弱いところや考慮の抜け漏れなど、十分にあり得ます。

その中で、今回のように

• 発注者（品質責任者）

• 開発会社

• 利用者

• ホワイトハッカー

• 有志の検証者

• 各サービス提供者

など多くの人が、それぞれに与えられた役割に対して向き合っていることが見て取れます。
それぞれがより自分たちの範疇において、しっかりとした知識・技術・責任をもって精進し、安心安全を心がけ、悪者を遠ざけ続ければ、よりよい世の中になり、それが真のDXといえるでしょう。
利用者もただその恩恵を享受するだけでなく、しっかり知識を身につけ自らの身を護ることが大事、ですね。

ここまで読んでいただいてありがとうございました。