こんにちは、「Assured」でプロダクトマネージャーをしている鈴木です。
去る7月13日に「ウェブ評価」という機能をリリースしたので、今日はその機能のご紹介とAssured自身での活用の様子をお届けしたいと思います。
「ウェブ評価」機能とは
「ウェブ評価」機能は、クラウドサービスの技術的なセキュリティ対策状況を評価する機能です。実際にアプリケーションにアクセスした結果に基づくHTTPヘッダの情報やDNSの設定情報などからセキュリティの対策状況を推定し評価します。
私たちはこの機能を、クラウドサービスをラーメン屋に例えて「ラーメン屋を、お店に入らずに門構えや外から見た行列、口コミから評価するような機能」と表現することがあります。本当に美味しいラーメン屋かはラーメンを食べてみるまでわかりませんが、それが良さそうなお店かどうかは外からでもわかることが多い、ということです。実際我々も、そのクラウドサービスにログインして使うことなく、インターネットに公開された情報を収集し可視化することでその安全性を推定し、評価レポートを生成しています。
「Assured」をウェブ評価してみた
せっかくなので「Assured」自身のウェブ評価を確認し、実際にセキュリティ対策状況を改善してみたいと思います。いくつかあるカテゴリの中から、今回は「HTTPヘッダ」と「メール」の項目を見てみます。
HTTPヘッダ
HTTPヘッダの評価結果は以下のようになりました。主にセキュリティヘッダと呼ばれるような、XSSやクリックジャッキング等の攻撃を防止するためのヘッダ情報を確認しています。これらのHTTPヘッダの設定値については、OWASPからもガイダンス等が公開されています。
ここでは 「Feature-Policy」 と 「Content-Type with character set」がうまく設定されていない様子が伺えます。特に「Content-Type with character set」は IPA の安全なウェブサイトの作り方テキストでもXSS対策として取り上げられており、正しく設定したほうがよさそうです。「Feature-Policy」については、「実験的な機能であり Permissions-Policy に改名されている」と MDN にも記載がありますので、「Permission-Policy」が設定されていれば問題ないでしょう。
他に、個人的な推しポイントで言えば Content-Security-Policy (CSP) が設定されていることでしょうか。CSPを安全な設定値で設定すると、XSS等により発生する意図しない（悪意ある）外部スクリプト・インラインスクリプトの実行を阻止することができます。一方で、外部サービスのAPIやSDKなどを利用している場合にはそれを明示的に許可しないとうまく動作しなくなってしまうこともあるため、セキュリティ対策として強力な反面、設定がしづらいものの一つです。「Assured」ではサービス開始当初からこのCSPを利用してサービスのセキュリティを高めています。
メールのなりすまし対策
メールのなりすまし対策の項目についても見てみたいと思います。
代表的な送信元ドメインの認証技術である「SPF（Sender Policy Framework）」はきちんと設定できていそうです。メールの送信ドメイン・サーバがブラックリストに登録されているかを判定する「Blocklist」についても問題ないという判定なので、自身のドメインからメールを送信する際に迷惑メールと判定されてしまう可能性は低そうです。
一方、「DMARC（Domain-based Message Authentication, Reporting, and Conformance）」については設定ができていませんでした。DMARCはSPFやDKIMを利用した認証結果の取り扱いやレポート先を指定できる仕様です。認証の結果、なりすましと見なされるメールを不審メールとして扱うように設定することで、なりすましメールによる詐欺行為等を防止する効果がありますし、認証結果のレポート受け取ることで、自身の管理するドメインがなりすましの疑いのあるメールに利用されていないかを把握することができます。
評価結果の改善
それでは、ウェブ評価で可視化された適切でない設定値を修正し、「Assured」のセキュリティ対策状況を改善したいと思います。
Content-Type の改善
実際に「Assured」の Content-Type レスポンスヘッダを確認してみると、以下のようになっており、確かに charset は指定されていませんでした。
$ curl -sI https://c.assured.jp | grep content-type: content-type: text/html
これは、利用している nginx サーバーで charset ディレクティブ が指定されなかったのが原因なので、これを追加して解決しました（以下の diff は nginx config の設定例です）。
http {
root /usr/share/nginx/html;
+ charset utf-8;
server_tokens off;
DMARC の改善
DMARCは、_dmarc サブドメインをつけたドメイン名にDNSでDMARCの設定値をTXTレコードとして登録することで設定できます。
例えば mail.yahoo.co.jp のDMARCレコードは以下のようになります。この設定では、認証結果を指定のメールアドレスにレポートするように設定されているほか、認証が失敗したメールについては不審なメールとして扱う設定となっています。（Yahoo!メールさんのDMARCに関する取り組みについては、Yahoo! JAPAN Tech Blog でも紹介されています。）
$ dig +short @1.1.1.1 _dmarc.mail.yahoo.co.jp TXT "v=DMARC1; p=quarantine; rua=mailto:mail_dmarc_report@yahoo.co.jp"
このように設定の際には認証結果のレポート先が必要となるわけですが、自身でそうしたレポートを管理するのも手間だったため、「Assured」では利用しているメールプロバイダが提携している ValiMail というSaaSを利用することにしました。DMARCを利用した認証結果のモニタリングを無料で利用できるサービスです。
assured.jp のドメインでも下記のようにDMARCレコードを登録し、レポート先には ValiMail のレポート用メールアドレスを指定しました。
$ dig +short @1.1.1.1 _dmarc.assured.jp TXT "v=DMARC1; p=none; rua=mailto:dmarc_agg@vali.email"
ValiMail 側でも設定をいくつか行い、以下のようにメールの認証状況がダッシュボードで可視化できるようになりました。なりすましメールは今のところ見当たらないようなので一安心です。
まとめ
「Assured」のウェブ評価機能を利用して、自身のサービスのセキュリティ対策状況を可視化し、実際に改善をしてみました。現在、このウェブ評価機能はクラウドサービス利用企業の皆さま向けに提供しており、クラウドサービス事業者様向けには提供していないのですが、この記事のように事業者側のセキュリティ対策の可視化・改善にも繋げられるものだと考えていますので、今後のアップデートにご期待いただければと思います。
「Assured」では、クラウドサービスを安全に活用するための情報提供の取り組みとして、このような技術的なアプローチも積極的に実装しサービスとして提供していきたいと考えています。少しでも興味を持った方は、ぜひカジュアル面談にご応募いただけたら嬉しいです。
エンジニアチーム紹介ページ
