世間でも騒がれるほど大きいサイバー攻撃が目立つ年だった2019年ですが、弊社で実施したセキュリティ対策についてまとめておきたいと思います。
フォームへの不正アクセス対策
Webサービスローンチ直後から、海外のIPアドレスから「お問い合わせフォーム」へ不正なアクセスが繰り返された案件がありました。
即座に対応が求められたため、Googleの reCAPTCHA v3 を導入して解決しました。
reCAPCHA v3
不可視のスコア判定をしてくれるモジュールで、v2の画像認証と比較してエンドユーザーのコンバージョンを落とすことなく導入できます。
導入した画面には reCAPCHAのアイコンが表示されます。
画像認証がないため、ユーザーには優しい反面、スコアや独自のロジックで OK/NG を決めるため、不正なアクセスでなかったとしても NG と判定されてしまう可能性があります。
v3はAI判定とのことですが、それが一定量まで無料で使用できるのでおすすめです。
下記で詳しく紹介されていますので、参考までに。
「reCAPTCHA」って？スパム対策に効果的なreCAPTCHAをフォームに入れてみた
https://www.synergy-marketing.co.jp/blog/using_recaptcha_on_form
reCAPTCHA v3 入れてみた
https://www.techscore.com/blog/2018/12/06/recaptcha-v3/
AWS IAMでの不正アクセス対策
これはお恥ずかしい話になりますが、弊社で過去検証用に利用していたものの、最近はノーメンテナンスとなっていたAWSアカウントのIAMに対して、不正アクセスをされてしまいました。
検証用ということもあり、過去に担当した人間が、簡易のパスワードでIAMアカウントを発行しており、以降更新されていなかったことが原因でした。
侵入されて、バージニアのリージョンでp3インスタンスを2日間起動されて、AWSからのアラートで検知しました。
本件を皮切りにAWSアカウントへは下記対応を実施しました。
・GuardDutyの有効化 (全リージョン)
・不要なIAMの整理
・IAMユーザーの２段階認証化
GuardDutyについては下記で詳しく紹介されていますので、参考までに。
【初心者向け】AWSの脅威検知サービスAmazon GuardDutyのよく分かる解説と情報まとめ
https://dev.classmethod.jp/cloud/aws/guardduty-summary/
SSHでの不正アクセス対策
SSHというと今更な感じもあり、秘密鍵を共有するのはどうなのか、という論点もあるかと思いますが、ひとつの案件で採用された方式のご紹介です。
SSHの接続元は「踏み台サーバ」に集約して、各サーバの秘密鍵を踏み台サーバに置かずに、ローカルに管理することで、鍵とIP制限の両軸でのセキュリティ強化を試みた例となります。
ssh web@yyy.yyy.yy.yyy –p20022 -o ProxyCommand='ssh -W %h:%p fumidai@xxx.xx.xx.xxx -p20022' -i ~/.ssh/id_rsa_web
無料で手軽に使えるSaasが増えた反面、過去に使った・作ったものをそのままにしておかず、きちんと管理・メンテナンスにもコストをかけていきましょう、という教訓を身を以て体感した1年でした。