はじめに

こんにちは。セキュリティ・ディレクション室/セキュリティスペシャリストの戸田　薫です。ヤフーのセキュリティを担当しています。 ヤフーでは、ユーザーへの安心・安全なサービス提供の実現にむけて日々取り組んでいます。今回は セキュリティに関する取り組みを簡単に紹介いたします。

• はじめに
• 日々、攻撃は行われている
• なぜ攻撃者は攻撃をするのか？
• セキュリティ対策の考え方
  • 攻撃は防げない
  • 問題は早期発見する
  • システムを堅牢化する
  • 多層で防御する
  • 権限を最小化する
  • システムに任せる
  • 専門家に任せる
• 脆弱性を埋め込まない・取り除くための組織体制のあり方
  • ガイドラインと教育を提供
  • システム・ソフトウェアの健康状態を確認し続ける
  • 脆弱性を探す
• 近年のセキュリティの取り組み
  • TLS 1.0 と 1.1 のサポートを終了
  • DNS CAA の 導入
  • プライベートバグバウンティのトライアル
• さいごに

日々、攻撃は行われている

「情報が漏洩した」、「不正利用があった」、「攻撃を受けた」、などの他社のセキュリティに関連したニュースを毎日のように目にします。当社のセキュリティ監視部門においても、ヤフーへなにかしらの攻撃が行われていることは、日々確認されています。

守れサイバーセキュリティ～SOCとは？ ヤフーにおけるその役割で紹介されている通り、 当社ではSOC(Security Operation Center)が監視業務を担当しています。主な業務は、攻撃を可視化とレポートです。見つかった問題については、CSIRTが対応します。

参考までにSOCのデータをお見せします。これは、当社従業員の業務用のメールの攻撃の件数です(注意：Yahoo!メールではありません)。メールのセキュリティ対策において、攻撃のタイプは主に、実行ファイル、ウイルス、スパムなどに分類されます。 中でも、「実行ファイルの添付」は多く見受けられる手法で、ある月では４０００件以上レポートされました。当社では、これら実行ファイルを自動的に削除し対応しています。

さらに、「実行ファイルの添付」の処理がなされた後には、ウイルスのチェックなどが入ります。正確な総数ではありませんが、ここからも多くのウイルスが当社に届いていることが分かります。

メール添付ファイルの手法について、もう少し詳しく見ていきます。 以下のグラフは、2019年の１月から８月にわたり、問題のあるメールの添付ファイルの拡張子ごとの件数を示しています。 時期によって、攻撃の流行が変わっていることがわかります。 １月から２月にかけてZIPファイル、５月から６月は、Excel（XLS)のファイルの件数が多くなり、時期により、攻撃の流行が変わっていることが分かります。

次のグラフは、ヤフーのあるネットワークのIDS（Intrusion Detection System）で検知されたものを示しています。攻撃の中で多いのは、「初期設定で攻撃可能なルータ」を探す行為で、毎日コンスタントに１００万件以上検知されています。集計の期間は４月１日から８月２２日までです。

ここまで、メールとネットワーク機器と異なるレイヤーの事例を紹介しました。攻撃はいろいろなレイヤーに対して、さまざまなパターンで行われ、しかも継続的に行われています。そのため、各レイヤーごとのセキュリティ対策が必要です。

なぜ攻撃者は攻撃をするのか？

ではなぜ、彼らは攻撃をしてくるのでしょうか？インターネット黎明期のサイバー脅威は、犯行者の自己顕示欲による愉快犯的な犯行だったと言われていました。しかし、現在では金銭目的が主流になり、攻撃側も組織的に大規模化しています。 攻撃者のモチベーションには、主に以下のものが考えられます。

• 特定企業や組織のビジネス価値の高い情報を得たい
• 金銭やポイントを得たい
• 政治的な信条などを世の中に示したい

例えば、ヤフーのようなサイトのユーザーアカウントを乗っ取れば、アカウントに紐付いているポイントやクレジットカードを利用して、商品を購入することが可能です。さらに、ユーザーのアカウントにクレジットカードが登録されていなくても、別途入手した他者のクレジットカードを登録することで、同様に商品の購入に利用し、現金化するなどの応用もできます。

企業が扱っている情報を奪われることにより、ほかの企業やユーザへの侵害など二次被害につながり、さらにそれの影響が拡大することもあります。 一企業での攻撃や不正利用への対応は困難なこともあるため、各企業が連携し、今後より一層力を合わせて対策を講じる必要があります。

セキュリティ対策の考え方

攻撃の手法が多様化し、攻撃は集団化・大規模化していく中で、セキュリティ対策の考え方をここで少しご紹介します。

攻撃は防げない

企業は攻撃の影響を減少させ、侵入されないための対策を実施する。しかし、攻撃は受けるもの。ゼロデイ攻撃などの解決手法が未知な状態で攻撃を受けるなど、すべての攻撃を防ぐのは困難です。そのため、「侵入されること」を前提とした対策を講じなければなりません。よって、「防御」だけではなく、「侵入を検知し対応」、「復旧」まで、一連のプロセスとして踏み込んで考えています。

対応方法を設計する上で参考になるのが、NIST（National Institute of Standards and Technology）の発行したサイバーセキュリティフレームワーク(Cyber Security Framework / CSF)です。このサイバーセキュリティフレームワークはサイバー攻撃対策に特化され、以下の５つの機能に分類されています。

1. 特定
2. 防御
3. 検知
4. 対応
5. 復旧

サイバーセキュリティフレームワークを利用することで、企業のセキュリティ対策の成熟度と「いま、どのような状況なのか？」を把握することができます。当社では、ISMS（Information Security Management System）やPCI DSS（Payment Card Industry Data Security Standard）の活用に加え、このサイバーセキュリティフレームワークも利用しています。上記の５機能を点数化し、現時点での成熟度を評価し、将来に向けて、どの領域をいつまでに改善していくか、という計画を考えています。

問題は早期発見する

そして、攻撃を受けないようにする１つの方法として、脆弱性を作りこまないことも重要です。 ウォーターフォールのようなサービスの開発から運用までを段階でわけると以下のようになります。

設計 > 開発 > テスト > リリース > 運用

一般的に、問題の発見が右側の段階に遅れるほど、対応への戻りが大きくなり、非効率になると言われています。 つまり右側に行くほど、「来週リリースなので修正できません」みたいな状況が起こりやすくなります。逆に左側で対処するほど、問題を修正する負担が小さくなります。

問題を作り込まない。また、問題を作っても、早い段階で発見し、対処するアプローチを実施。そのために、段階ごとに、以下のような対策が考えられます。

システムを堅牢化する

堅牢化とは、ハードニング(Hardening)とも言われます。 システムを堅牢化することで、攻撃を受ける可能性を減らすことができます。 Unix のシステムで言えば、いくつかを例に挙げますと、以下のような対応が考えられます。

• ソフトウェアを最低限にし、不要なものは削除する
• 不要なデーモンは停止する
• 不要なアカウントは削除する

多層で防御する

未知の攻撃に対応することは困難な一方、セキュリティ対策の中で可能なことは、「既知の攻撃」の対策です。多くの企業でビジネス体制や業務環境、コストなど様々な要因で、セキュリティだけを優先することが難しいのが状況です。前述のように突破されてしまう前提に立ち、防御のシステムを多層化し、既知の攻撃へ対応することも重要です。

例えば、攻撃がメール経由で行われる場合、外部からのメールを受け付けないのは、一番簡単な方法です。しかし、通常のビジネスで社外の方とコミュニケーション上、メールは必須のツールであるため、この対策は現実的ではありません。一方でメールの利用により、業務端末は攻撃を受けやすい環境下に置かれています。ある程度、自由に使える業務環境が必要だとすれば、業務端末は、攻撃を受けやすい環境であると言えます。

この現象を解決するためにヤフーでは、ネットワーク、端末、アプリケーションなどあらゆるレイヤーで対策を講じています。 アカウントの保護のために、ユーザーレベルでは、二要素認証などが一般化してきていますが、業務環境の認証においては、複数の要素で認証を行っています。パスワード、公開鍵、証明書、OTP(One Time Password) , 認証アプリケーションなどを活用した対策を講じています。例えば、ヤフーのサービスのサーバにログインするためには、踏み台サーバと呼ばれるゲートウェイサーバを経由しなければなりませんが、その踏み台サーバでは公開鍵認証とOTPを採用しています。

権限を最小化する

システムの設計・運営のみでなく、「利用者」に対しても考慮が必要です。セキュリティ運営においては、必要以上に人やシステムに権限を付与するべきではありません。 アカウントやシステムが乗っ取られた場合に、利用権限が少なければ、影響範囲もそれだけ小さくなります。 以前サービスの WebAPI は証明書ベース認証のアクセス制御を行っていました。しかし、現在、サービスの WebAPI は、Athenz と呼ばれる認証認可の OSS が使われています。

システムに任せる

システム的に制限できることと、できないことがある事も留意しなければなりません。システム的に制限できないものは、当然、人間の介入が必要になります。また、人数やルールが多くなるほど、運営や体制の難易度が上がっていきます。そのような状況を想定し、「意識しなくて、なにもしなくても、守られている状態」を念頭に体制を設計しています。

前述したメールの実行ファイルの添付による攻撃の場合、「怪しい添付ファイルは開かないでください」とルールを作り、それを周知していても、うっかり開いてしまうことは発生します。また、メールのシステムや業務端末など各レイヤーで、ウイルスチェックを実施します。しかし、未知のウイルスであれば、ウイルス対策の製品をすり抜けて、実行ファイルが実行されてしまうことも考えられます。この場合、根本から対策を講じることが必要だったため、添付ファイルの実行ファイルを自動的に削除する方法を採用しました。この結果、社員は「メールに添付された実行ファイル」に注意を払う必要がなくなりました。

通常の業務でシステムとシステムの間に、人手が入ることもよくあります。この場合、セキュリティレベルの低い環境下に、個人情報が入り込む事を想定し、可能な限りシステム間の連携を構築し、間に人を挟まない方針をとるべきです。人手が入ると、思ってもなかったところに個人情報などが蓄積されたり、メールでの誤送信なども発生しやすくなります。自動化とコストの兼ね合いや頻度など、いくつもの要素を勘案しつつ、自動化していくのが望ましいと考えています。

専門家に任せる

さらにシステムや業務の共通化・分業化を進め、各領域のプロの知見でしっかり検証できる環境作りも同時に行っています。一人がすべてのスタックを担当するためには、多くの知識が必要であり、それためには情報収集や確認作業にも時間がかかります。結果、サービスのキモであるビジネスロジックの開発・改善に集中できなくなり、市場での競争力を失ってしまいます。ヤフーで共通化・分業化を進める背景には、複雑化・専門化する領域はプロフェッショナルに任せ、サービス担当者はビジネスロジックにできるだけ集中してもらうことを目指しています。

脆弱性を埋め込まない・取り除くための組織体制のあり方

今までは、具体的な運用方法を中心に話してきましたが、それらを実現するための「脆弱性を埋め込まない・取り除く」組織体制について、少し踏み込んで説明いたします。

ガイドラインと教育を提供

セキュリティ領域に限らず、開発の段階では、守るべきガイドラインを提供しています。 RFC（Request For Comments）で利用される "must" （しなければならない）を用い、関係者間での認識とプラクティスの統一化を図っています。 さらに社内用のTLSガイドラインでは、要求する仕様をまとめ、具体的なプロキシなどの設定は、下位ドキュメントのプロシージャで明記しています。

また、人は知らないことは実施できません。サービスを開発して提供する側は、往々にして自分たちでセキュリティの問題を作り込んでしまう場合もあります。よって、社員に対し、そうした問題を回避するための適切な教育を実施していくことが大切です。ヤフーでは、社員向けセキュリティ教育を職種・役割ごとにカスタマイズして提供しています。

経営層向けには、セキュリティ業界で有名な名和利男様に教鞭をとっていただいています。

エンジニア向けには、

• セキュアプログラミング
• Micro Hardening などの技術系を中心としたコンテンツが提供されています。

セキュアプログラミング研修は、ウェブアプリケーションセキュリティの第一人者である徳丸浩様(EGセキュアソリューションズ株式会社)が担当されています。以前はPHP全盛でしたが、近年はヤフー社内の標準言語が変更されたため、研修は Node.js や Java, PHP のコースが提供されています。また研修では、ヤフーのセキュリティに対する取り組みについて 第1回目で紹介されている一般的なものを対象としています。 受講方法は、セミナー（集合研修）と eラーニング （動画） から選択可能です。時間や場所に縛られずに研修が受けられる体制にしています。

さらに、サイバー攻撃を想定した実践型セキュリティ演習 Yahoo! JAPAN Hardening を実施しています。

システム・ソフトウェアの健康状態を確認し続ける

人は、健康診断を受けて、自分の健康状態を確認し、問題が見つかれば、治療をします。 システム・ソフトウェアの世界では、システム・ソフトウェアの健康状態を確認して、バグ(問題)が見つかれば、修正しなければなりません。

ヤフーでは、攻撃を受けにくくする対策の１つとして、脆弱性の対応を実施しています。

YJ-CSIRTの 脆弱性に対するヤフーの取り組みについて でも紹介していますが、脆弱性の確認は、リリース前からリリース後まで、いろいろな手段を織り交ぜてやることになります。 ビルド・テストとデプロイは、CIやCDで行われるのですが、その中で、自動的にセキュリティがチェックされ、問題があれば、デプロイされないように対応を進めています。

当社では、商用ソフトウェアやオープンソースソフトウェアをたくさん利用しています。各ノードに導入されているソフトウェアの情報を収集し、脆弱性の混入状況を可視化してきました。CSIRTは脆弱性情報を収集し、社内へ脆弱性情報の共有を行い、脆弱性のつぶしこみの支援を行っています。 検出と可視化は、内製のツールを開発・利用してきましたが、近年は、SourceClear を利用しています。

脆弱性を探す

脆弱性診断については、以下の２つがあります。

• 自社での脆弱性診断
• セキュリティベンダーによる脆弱性診断

自社は、CSIRTが定期的にネットワークレベル、アプリケーションレベルの診断を回しています。 ネットワークレベルでは、Nessus を利用しています。アプリケーションの診断には AppSpider を利用しています。

PCI DSSの対象のサービスについては、さらに診断が実施されています。 PCI DSS には、NexPose を利用しています。

近年のセキュリティの取り組み

近年の当社でのセキュリティの取り組みはいろいろありますが、いくつか事例をあげると以下のものがあります。

• TLS 1.2 対応
• DNS CAA 導入
• プライベートバグバウンティ

TLS 1.0 と 1.1 のサポートを終了

ヤフーでは、2018年に「TLS 1.0 と 1.1 のサポート」を終了し、現在はTLS 1.2のみをサポートしています。これは、クレジットカード業界の PCI DSS (Payment Card Industry Data Security Standard) に則り TLS 1.0 を 2018年6月までにサポートを終了する必要があったため、PCI DSS の対象範囲外もふくめて、古い TLS のサポートを終了いたしました。

Yahoo!ウォレットやYahoo!かんたん決済は、PCI DSS に準拠しています。クレジット業界のルールに準拠し、安全な決済サービスを提供していく上で、古いTLSバージョンのサポート終了を以前より検討しておりました。 以下にヤフーのサービスで幅広く集計したグラフを掲載します。

グラフで示されている通り、2017年から2018年にかけて、TLS 1.2 は右肩上がりです。TLS 1.0 は、徐々に下降しており、TLS 1.1 はほとんど横ばいです。しかし、サービスやアプリを分母にして見た場合では、傾向が異なっており、状況はさまざまでした。幅広く平均を取った場合でも、2017年の年末でもTLS 1.0の割合が 3.7% 以上もありました。この数字は、ヤフーのビジネスに対するインパクトは十分に大きいと言えました。しかしながら、安全な環境を提供する義務もあります。そこで、ビジネスインパクトを抑えつつ、安全な環境を提供していくために計画を立てました。

最初に事務局を作り、全体の計画を立て、その後、２つのチームを作りました。

• 事務局
• 技術チーム
• 告知チーム

事務局には、主要サービス領域のセキュリティ責任者やテクニカルディレクター、広報やカスタマーサポート担当など、サービスを網羅的に見ている人物を集めました。 また、各サービス現場の旗振り役を担う技術チームや告知チームには、各サービス部門から1名ずつ選任してもらいました。まさに、当社が一丸となって取り組みました。

どのサービス・アプリをどうするのかをすべて決める必要があっため、サービスとアプリをリストアップし、３チームが連携して対応方法やスケジュールを決定していきました。

考慮する接続のポイントを以下に示します。

• OSとブラウザ
• OSとアプリ
  • ネイティブ通信
  • WebView
• パートナーとのシステム連携
• ヤフー内のサーバ通信

ユーザーには、さまざまなチャンネルを通じて告知を行いました。パートナーには、主に営業を通じて告知を行いました。

• セキュリティセンター
• サービスごとのトップページ
• ページ上部のお知らせ枠
• ヤフー公式Twitterアカウント

また、告知に伴い、以下のものを提供しました。

• ブラウザ判定ページ
• 検証環境

ユーザーへの影響を極力抑えるためにどのような順番で TLS 1.0/1.1 のサポートを終了するか、検討していました。 事例として、ヤフオク!を紹介します。ヤフオク!は、入札から落札後の手続きの完了まで時間がかかります。 TLS 1.2 をサポートしないブラウザやアプリでは、落札後に TLS 1.0/1.1 のサポート終了を迎えてしまうと、落札後の手続きができない懸念がありました。これだと落札者も出品者も困ってしまいます。 そのため、ヤフオク!では、 TLS 1.0/1.1 のサポートの終了前に、 TLS 1.0/1.1 の通信を行っている環境からの入札の制限し、この問題を回避しました。

この取組では、パートナー企業、広告の配信先、ヤフーのウェブやアプリなど、考慮すべき点が多数あり、社外社内問わず、いろいろな方にご協力頂き、進めることができました。 iOS に比べて、Android は OS のフラグメント化(複数のOSバージョンが利用されている)が激しく、影響を受ける範囲が大きかったのが特徴的でした。

ヤフーへの通信の TLS のバージョンのモニタリングを行っていますが、TLS 1.0 / 1.1 の通信の割合は、１年前に比べるとかなり少なくなっています。ユーザー環境の TLS 1.2 への移行がかなり進んでいると予想されます。

現在は TLS 1.3 のサポートの準備を行っています。安全性の向上と高速化の両方が期待できると考えています。

DNS CAA の 導入

証明書の誤発行・不正発行を防止するため、証明書の認証局は、DNSのCAA（Certification Authority Authorization）レコードを確認するようになっております。

SXG（Signed HTTP Exchanges）始めましたで紹介されている通り、SXG証明書を導入しました。 SXG証明書の要求事項として、DNS CAAのチェックが必須であり、DNS CAAも導入いたしました。

dig コマンドで簡単に確認することができます。

$ dig caa yahoo.co.jp
; <<>> DiG 9.10.6 <<>> caa yahoo.co.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46930
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;yahoo.co.jp.            IN    CAA
;; ANSWER SECTION:
yahoo.co.jp.        888    IN    CAA    0 issue "globalsign.com"
yahoo.co.jp.        888    IN    CAA    0 issue "cybertrust.ne.jp"
yahoo.co.jp.        888    IN    CAA    0 iodef "mailto:nic-admin@mail.yahoo.co.jp"
yahoo.co.jp.        888    IN    CAA    0 issue "digicert.com;cansignhttpexchanges=yes"

;; Query time: 46 msec
;; SERVER: 172.19.1.64#53(172.19.1.64)
;; WHEN: Fri Jul 26 19:11:17 JST 2019
;; MSG SIZE  rcvd: 216

プライベートバグバウンティのトライアル

脆弱性をゼロにすることを目指して、各段階で対策を入れておりますが、当社だけでは見つけられないバグもあると考えています。セキュリティベンダーによる脆弱性診断も毎年受けていますが、サイトの規模も大きく、サービスの数も多いため、完全にチェックするのは非常に難しいです。また、いろいろな専門家の目で見てもらう必要があります。

「初期設定で攻撃可能なルータ」を探す事例で紹介した通り、毎日のように脆弱性を探すようなリクエストが届いていますが、脆弱性を探している人たちがいます。 その人たちは、見つけた脆弱性を攻撃に使うこともできれば、ダークウェブで販売することもできます。 攻撃をしたい人たちは、ダークウェブで脆弱性を購入することもできます。

一方で、脆弱性情報は、ダークウェブで売買されています。なぜ売買されるかというと、見つけた脆弱性を売りたい人がいて、脆弱性を利用して攻撃を行いたい人がいるからです。 ダークウェブに出回るのを防止するのは困難ですが、流通する量を減らす対応の１つとしてバグバウンティが考えられます。バグバウンティは、「脆弱性報奨金制度」と呼ばれています。バグバウンティは、脆弱性の発見者（一般人のホワイトハッカー）に対価を支払う制度のことです。

自社および外部セキュリティベンダーの脆弱性診断は、広く浅く、基本的なところを確認し、バグバウンティでは、なかなか見つけ辛いところを確認できるのでは？という予測のもと、昨年にプライベートバグバウンティのトライアルを実施しました。 バグバウンティは、自社で行う方法とバグバウンティのプラットフォームサービスを利用するやり方がありますが、当社では、バグバウンティプラットフォームのサービスを利用しました。 当社には多数のサービスがあるため、いくつかのサービス（実際にはFQDN（Fully Qualified Domain Name））に絞り込んで、実施しました。 バグバウンティを自社だけでやるか、プラットフォームサービスを利用するかは、CSIRT の体力(人的リソースやスキル)や予算次第だと思います。バグ報告を受け付ければ、良い報告もあれば、参考にならない報告も来ます。たくさんの報告の中から有効なものを探し出すのは、意外と骨が折れます。

実際に当社が作り込んだバグを発見することができ、バグバウンティ自体は有効だったと判断しています。 今では使われていない古いファイルがいまだに公開されたままになっていたものがバグとして報告されました。使用しなくなったものをきちんと処分しなければならないという当たり前の課題も発掘できました。 日本語のみのサイトの場合は、海外のバグバウンティのプラットフォームの社員の方や外国のホワイトハッカーの方からすると、対象のサイトのIDを取得するのが難しいというバグバウンティを実施する上での課題もありました。

さいごに

繰り返しになりますが、ヤフーでは、ユーザーへの安全・安心なサービス提供の実現にむけて日々取り組んでいます。 今後もヤフーのセキュリティの成熟度を上げていき、ますます安心してご利用できるサービスの提供の実現に励んでいきます。