UTALI

みんなの役に立つ情報をどんどん公開していきます

【翻訳】Web開発セキュリティチェックリスト

安全で頑健なウェブアプリケーションをクラウドで構築するのは実に大変です。 もし簡単だと考えているのなら、きっとあなたは相当高いスキルを兼ね備えているか、あとで痛い目を見るかの2択でしょう。

もしも奇抜なアイディアが思い浮かんで1ヶ月でそれをプロダクトとして発表したいと考えているのなら、何度もアイディアを練り直した上でプロトタイプを先に製作することをおすすめする。

以下のチェックリストをみなおした上で、多くの重要なセキュリティ問題を無視しようとしている可能性について認識してほしい

最低でも、あなたの作ったサービスに正直に、完全なものではなく、セキュリティに問題のあるプロトタイプであることを伝えるべきだろう。

このチェックリストはシンプルで、全く完全ではない。それはウェブアプリケーションを作成する上で、重要な問題であると、だけ言っておきます。

データーベース

  • 暗号化を利用する - 特にユーザーの個人情報やメールアドレス、アクセストークン、取引の履歴など
  • もしデーターベースが低コストの暗号化を提供していたら、それを有効化した上で、全てのバックアップも同様に暗号化されるようにする。
  • データーベースにアクセスするユーザーの権限は最小限に止める。rootユーザーは利用しない
  • 秘密鍵は専用のキーストアに分散して保存しておく、アプリケーションにハードコードしてはいけない
  • SQLインジェクションを予防するために、SQLのプレペアドステートメントを利用する。Node.jsでの例を挙げるとnpm-mysqlではなくnpm-mysql2を利用するなど

開発

  • ソフトウェアのすべてのバージョンについて脆弱性の検査を行う。これはO/S、ライブラリやパッケージ、またCI-CDプロセスに組み込むべきである。
  • プロダクション環境と同レベルで安全な開発環境を利用する。ソフトウェアを安全で隔離された開発環境で行う

認証

  • すべてのパスワードは適切なアルゴリズムを利用してハッシュ化を行う。決して自作のアルゴリズムを使ってはならない、もし暗号化に適切な初期値を与える必要がある場合はその初期値の与え方にも注意する。
  • ユーザーに安全で十分な強度を持ったパスワードを設定させるようにする。
  • 二段階認証を利用するなど安全なログインができるようにする

Dos攻撃

  • サービスに障害を発生させるようなDoS攻撃対策を万全にする。最低でもログインやトークンの発行などにはレイトリミットを設定して、短時間に大量のアクセスができないようにする。
  • 送信できるデータのサイズに上限を加えたり、特定のデーター形式以外は拒否するなどのサニタイズを万全にする
  • CloudFlareなどのグローバルキャッシングプロキシを利用してDDos攻撃に備える。これはDDOS攻撃を受けた時に被害を軽減することにつながる。

Webトラフィック

  • TLSをサイト全体で利用する。ログイン用フォームだけでは、TLSをフォーム単体で利用すべきではない
  • CookieはhttpOnlyで利用した上で、パスとドメインを限定する。
  • CSPを危険なバックドアを許可しないために利用する。この設定は面倒だが、見合う価値がある。
  • X-Frame-Optionを有効化する。X-XSS-Protectionヘッダをクライアントのレスポンスに設定する。
  • HSTSレスポンスとTLSアクセスに限定するために設定する。すべてのHTTPリクエストをHTTPSにリダイレクトする。
  • すべての入力フォームでCSRFトークンを利用する。そして新規の同一ドメインCookieを利用して、CSRFを一度だけ利用するようにする。

APIs

  • 公開APIで不用意にデータをアクセスさせないようにする。
  • すべてのユーザーが認証済みで、適切な権限を与えるようにする。不必要に大きな権限を与えない

検証

  • ユーザーの素早いフィードバックのためにクライアントサイドでのバリデーションを実行する。サーバーでも2重のバリデーションを行う
  • サーバーサイドでホワイトリストやスキーマを利用してユーザーの入力したデーターのバリデーションを行う。決してユーザーの入力したデータを直接利用してはいけない。当然SQL文をそのまま利用することなど論外

クラウドの設定

  • どのサービスも最低限のポートを開けておく、曖昧さによるセキュリティは何の対策もしていないことと同じ、通常とは異なるポートを利用すると攻撃者に少々やりづらくさせる。
  • グローバルな環境からはアクセスできないプライベートVPC内にバックエンドのデータベースやサービスを配置する。特にAWSでセキュリティグループを設定してピアとなるVPCを設定する時には注意する。これはうっかりバックエンドを公開する危険性があるからだ。
  • アプリケーションのロジックとなるサービスは隔離されたVPC内で利用する。ピアとなるVPCはサービス内通信を利用する。
  • すべてのサービスはアクセス可能なIPアドレスを制限する。
  • 通信可能なIPアドレスとポートを制限する。
  • AWS IAMを常に利用してrootクレディンシャルを利用しない
  • 各データにアクセスできる開発者スタッフに制限を設ける
  • 定期的にパスワードとアクセスキーを変更する

インフラ

  • サービスを停止させることなくアップグレードができるようにする。ソフトウェアを自動的にアップデートできるようにする。
  • Terraformのようなツールを利用してインフラを構築する。クラウドのコンソールを使ってはいけない。基本的にコードで構築するようにして、シェルスクリプトなどを利用して一発で再構築できるようにする。
  • すべてのサービスのログを収集するサービスを別に構築する。SSHなどで直接ログを取得するのは得策ではない
  • SSHを偶発的な診断ではなく、定期的な診断のために利用すべきではない。それは基本的な仕事を自動化できていないことを意味するからだ
  • 22ポートをAWSのあらゆるサービスグループに対して開くべきではない
  • イミュータブルホストを作成して、自分自身で更新、パッチを当てるサーバーの代わりに利用する
  • SenseDeepのような侵入検知サービスを利用する。

オペレーション

  • 利用していないサービスやサーバーは停止する。もっとも安全なサーバーは稼働していないサーバーであるから

テスト

  • 設計と実装について監査を行え
  • 侵入テストを行え、自分自身で構築したサービスにクラッキングを試みる。もし可能なら第三者にも実行してもらう。

最後に、プランを立てる。


* 事故が発生した場合の対処法を考える。考えられる脅威とその対抗策を考えておく
* インシデントが発生した場合のプランを考えておく、将来必要になるかもしれないから

simplesecurity.sensedeep.com