[AWS+WordPress]今さら聞けない二段階認証(MFAデバイス)でのセキュリティ強化

聞くとヤバいので本当に今さら聞けないセキュリティ対策

 枯れた技術の入門記事で「今さら聞けない」を枕詞にしたものをよく見ますが、「本当に聞けない」のがセキュリティ対策です。なにせ「知らない」「やってない」ことがバレた時点で「セキュリティ甘々なサイト」と他所様に認識されてしまうのですから……。

 この数か月で少しAWSとWordPressに詳しくなったので、復習がてら導入のアドバイス・コンサルティングを始めました。お客様のお話をお伺いしていると情報セキュリティへのご関心が高いようです。WordPressは有名CMSなので、セキュリティホールを突く攻撃から面倒くさいコメントスパムフォームスパムまで日々痛い目に遭っている方が多いようです。

 私自身は情報処理安全確保支援士(SC)の資格など持っていませんし、そもそもエンジニアですらありません(アドミン君でないとは言い切れませんが……)。従ってセキュリティを語る資格は無いのですが、現実問題としてウェブサイトを立てた瞬間からセキュリティのリスクと責任を負ってしまうのでどこぞの予約サイトのようにセキュリティを全く無視するわけにはいきません。

今さら「入れない」では済まない二段階認証(多要素認証=MFA)

 昔は二段階認証と言えばオンラインバンキングなど金融系が中心でした。しかし、ここ数年でセキュリティ事故による情報流出が多発し、IDパスワードが攻撃者に奪われてしまいました。

 その結果、各種のサービスに不正取得したIDパスワードを使って侵入し不正送金などを行い、ユーザーが深刻な被害を受ける事件まで起こってしまいました。その結果、みんな大好きメルカリやYahoo!/PayPayを筆頭に、一般的なサービスでもすごい勢いでワンタイムパスワードによる二段階認証が普及しています。

 二段階認証で幅広く使われている方式は、下記となります:

  1. トークン(認証専用ハードウェア)による認証
  2. 携帯電話・スマホのSMSによる認証
  3. スマホの認証アプリによる認証(これが当記事のテーマです)

 これらの方式をセキュリティ用語では『MFAデバイス』、特にスマホアプリによる方式を『仮想MFAデバイス』と呼びます。MFAはMulti-Factor Authenticationの略で、直訳すると『多要素認証』となります。

 個人サイトではトークンやSMSによる認証は難しいので、3.の『スマホの認証アプリによる認証』に頼ることとなります。しかし、予備知識がないと「認証アプリってなに?」「どの認証アプリを使えばいいの?」と頭がはてなマークで埋め尽くされてしまいます。

ワンタイムパスワードには共通規格がある(RFC 6238 – TOTP)

 結論から申し上げると、二段階認証で使われるワンタイムパスワードの方式には共通規格があります。『RFC 6238 – TOTP: Time-Based One-Time Password Algorithm』というもので、ざっくり言うとSSLなどと同じレベルです。

 従って、AWSやWordPressに二段階認証を入れようと思ったら、まず最初にやることは『TOTP対応の認証アプリ』のインストールです。「TOTP対応なら、どれでも良い」ということです。Googleで検索してみると、下記のような認証アプリがヒットします:

注意点① アプリ認証はSMS認証に依存している

 実際に認証アプリを使う前に、絶対に確認しておくべきことがあります。スマホをなくしたり壊したりしてしまったら、アプリ認証も出来なくなってしまいます。従って、二段階認証を入れる前に、必ず認証アプリの機種変更方法を把握しておかなければいけません。私が使っているIIJ SmartKeyで機種変更を行うための本人確認は、SMS認証を用いています:

 これが意味することは、「電話番号を変えてしまったら認証アプリの機種変更が出来なくなり、ワンタイムパスワードも最終的には使えなくなる」ということです。アプリによって本人確認の方法は異なる可能性がありますが、頭の片隅に置いておいて下さい。

注意点② AWSの二段階認証はルートユーザーとIAMユーザーの両方で必要

 セキュリティ重視の方は、AWSでもユーザー登録時に付与されるルートユーザーではなく別途IAMユーザーを作成して運用していることも多いかと思います。しかし当然ながら、仮にふだんは使っていないとしても、ルートユーザーも二段階認証を入れないとIDパスワードを抜かれたら終わりです。

ルートユーザーに二段階認証を入れるメニューは『マイセキュリティ資格情報』(2021年5月現在)
AWSの二段階認証は『多要素認証(MFA)』という名称

注意点③ WordPress自体にも二段階認証を入れないと意味がない

 WordPressは一般的にブログなどを公開するウェブサイトと同じサーバーに管理画面があり、ウェブ上で記事を編集します。WordPressは5.xの時点では本体に二段階認証の機能がないため、サードパーティーの認証プラグインを入れる必要があります。WordPress 6.xでは絶対に改善してもらわないと困る状況ですが、いま出来ることとしてWordfence Security – Firewall & Malware Scanを入れています。

 正直、CMS全体の動作に大きな影響を与えるセキュリティ関連でサードパーティーのプラグインを入れるのは怖いので、「インスタンスのバックアップを取った上で恐る恐る入れている」というのが本音です。

 私自身は無職でノマド()なのでWordPressに接続するIPアドレスを固定するのが難しい状況ですが、企業ユーザーの方などでIPアドレスの固定が可能な方は、IPアドレスの指定による管理画面へのアクセス制限が可能かどうか、併せてご検討されるのがよろしいかと思います。

まだの方は今すぐ始めて下さい

 正直、情報セキュリティ関連の投稿は、自分の手口を明かしてしまう上に本職のエンジニア様などによる恐ろしいマサカリにも晒されているので「書きたくない😭」のが本音です。

 しかし、非エンジニアの方が多く利用しているWordPressがセキュリティ面で脆弱な状況に置かれている現状は非常にまずいと感じたため、敢えて二段階認証の投稿をするという決断をしました。

 このような状況ですので、セキュリティが本職の皆さまが当記事に問題を発見した場合は、何卒、優しくご指摘ください。ご指摘そのものは、当サイトのセキュリティ改善につながるので歓迎です。

Cloudfront+LightSailでコンテンツ配信サービス(CDN)を作る

自前主義なら動画まで

 「自前主義で行こう」と独自ドメインでサイトを再開した私ですが、動画はYouTube先生に依存しています。動画はファイルが大きいので自分のサイトに置くのは正直怖いのですが、自前主義をテーマにしてみたので動画もサイトに置いてみることにしました。

LightSailは安いがしょぼい

 LightSailはAmazonの格安ホスティングサービスで「月額 3.50 USD から」が売りです。お財布に余裕が無い私は迷わず3.5ドルコースを選びましたが、スペックは下記のようなものです。

 うちのパソコンよりしょぼいです💦 無名サイトなので余裕ではあるのですが、動画を置くのは怖い。というわけで、Amazonのコンテンツ配信サービス(CDN) 『CloudFront』を入れてみることにしました。

 CloudFrontはWebサーバーのファイルをキャッシュして配信を代行してくれるサービスです。CodeZineによれば「東京における16のCloudFrontエッジロケーションおよび1つのCloudFrontリージョナルエッジキャッシュ、2つのAWS Direct Connectロケーション、大阪における1つのCloudFrontエッジロケーション、および1つのDirect Connectロケーション」とあり、2021年3月時点で日本国内に17か所の配信サーバーがあります。

 これならWebサーバーがしょぼいままでも、動画をCloudFrontに置けば、万が一アクセスが増えてもサーバーが落ちる事態は防げそうです。

で、CloudFrontはナンボなの?

 「でも、お高いんでしょう?」

 特に仕事でアカマイなどのCDNを入れたことがある方は、とても、とても心配になると思います。実際、企業向けのサービスなので多少の出費は覚悟する必要があります。具体的には、

 日本向けの料金が1GBあたり0.114ドルです。20MBの動画が月間1万再生されると約200GBになりますので、月22.8ドルになります。

「やはり、お高い……」

 しかしここはぐっと歯を食いしばって「1万再生もあれば22.8ドルくらいの収入は期待出来るだろう」と前向きに考えます。

CloudFront、なんとか動きました

 その後試行錯誤した結果、なんとかCloudFrontを動かすことが出来ました。

$ curl -svo /dev/null https://cf.can.ne.jp/v/my-domain-in-2020s.mp
4
*   Trying 54.239.169.55:443...
* Connected to cf.can.ne.jp (54.239.169.55) port 443 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /opt/bitnami/common/openssl/certs/curl-ca-bundle.crt
*  CApath: none
...
< HTTP/1.1 200 OK
< Content-Type: video/mp4
< Content-Length: 13960998
< Connection: keep-alive
< Server: nginx
< Date: Mon, 12 Apr 2021 09:15:50 GMT
< Last-Modified: Mon, 12 Apr 2021 08:33:00 GMT
< ETag: "607405bc-d50726"
< X-Frame-Options: SAMEORIGIN
< X-Cache: Hit from cloudfront

X-Cache: Hit from cloudfront

 次回以降、どのような設定を行ったかをゆっくり書いていきたいと思います。

WordPress Multisiteを選ぶべきか

 AWS LightsailのWordPressには通常版とマルチサイト版(WordPress Multisite)の二種類があります。どちらを選んでも致命的な影響はなさそうですが、複数のサブドメインでWordPressを展開したいならMultisiteを選ぶ余地があります。

 上図がWordPress Multisiteと一般的なWordPressの違いです。

 「① 一般的なWordPress」では複数のサブドメインを展開するために同数のLightSailインスタンスを作る必要があります。インスタンスごとにリソースを確保するので、リソースを使い切らない小規模のサイトでは割高になります。一方で、特定ドメイン用のインスタンスを停止しても他のサブドメインに影響が無いと言った利点もあります。

 「② WordPress Multisite」では単一のLightSailインスタンス内で複数のサブドメインを展開出来ます。プラグインなど管理が一元化されるほか、LightSailインスタンスをひとつしか起動しないのでアクセス数が少ないうちは料金的にお得になります。ただし、一般的なWordPress用のプラグインが使えなくなる(有償契約が必要など)ことがあるため、初心者やサブドメインの展開予定が全くない場合は避けた方が良さそうです。

 また大規模なアクセスを期待出来るサイトの場合は、LightSailインスタンスのリソース制約があるのでWordPress Multisiteは避けた方が良いでしょう。「そもそもLightSailで大規模サイトを運用するのか?」という話もありますが💦

長期の仕事を探しています

デジタルマーケティング関連の仕事を探しています❢

 今春から長期の仕事を探しています。40代なので「採用はちょっと……」という人事ご担当者様も多いと思います。正直20代の元気な方のような伸びしろはありませんが、当サイトでスキルレベルが適切と思われた方は、お気軽にお声がけ頂ければと思います。下記フォームかツイッター(https://twitter.com/masarumkt)、あるいはメール(masapon05 アットマーク gmail.com)でご連絡下さい。

    ようやく常時SSLになりました(Let’s Encrypt)

     ウェブマーケ畑の人間なら1日も早く導入したいSSL。個人サイトということもあり、定番の無償SSLであるLet’s Encryptを導入しました。LightSail環境で立ち上げたWordPressなので一般的な環境と少し異なるので、メモしておきます。

    Generate And Install A Let’s Encrypt SSL Certificate For A Bitnami Application

     https://docs.bitnami.com/aws/how-to/generate-install-lets-encrypt-ssl/#step-5-renew-the-let-s-encrypt-certificate

    bncert-toolというBitnami専用のツールをAWS Lightsailのコンソール上で行います。設定自体はとても簡単ですが、certbotの手順とは異なるので注意が必要です。

    certbot instructions(一般的なdebian – apacheの場合はこちら)

    https://certbot.eff.org/

     ブログのようなオープンなサイトではSSLはセキュリティ面で必須とは思いませんが、Webブラウザで派手な警告が出ること、Google検索などで低評価を受けることを考えると個人サイトでも不可欠との認識です。

     技術畑ではない人にはどんどん敷居が高くなる独自ドメインでのサイト構築ですが、何とか時代の変化を追い続けてサイトを延命することには自身のスキル維持という意味でも重要と思います。