1. セキュリティ
個人情報の漏えいなど事故が起きれば、一発退場になりかねません。
Security is our first priority.
エクメルンでは以下の流れでセキュリティ対策に取り組みました。
- セキュリティリーダー選出
- 情報収集
- 学習
- 社内診断準備
- 社内診断
- 社外診断
- 情報公開
- 運用改善
1.1. セキュリティリーダー選出
セキュリティ周りをリードするセキュリティリーダーを決めます。
1.2. 情報収集
セキュリティリーダーがセキュリティ対策や社内診断ツールに関する情報収集を行います。
ポイント
- セキュリティは重要なので、慣れていても念のために情報収集から始めた方がいいと思います。勘違いやあいまい、思わぬアップデートがあるかもしれません。
参考にした書籍やサイト
- 「体系的に学ぶ 安全なWebアプリケーションの作り方」 徳丸 浩氏 セキュリティ対策の経典ともいうべき本です。必読です。
- 「Web API: The Good Parts」水野 貴明氏 WebAPIに関するセキュリティのプラクティスが書かれており、わかりやすくて実践的な本です。
「安全なウェブサイトの作り方」IPA
こちらもセキュリティ対策の経典ともいうべき資料です。非常にわかりやすい内容で必読です。「SSL/TLS暗号設定ガイドライン～安全なウェブサイトのために（暗号設定対策編）～」IPA
IPAが発行している、SSL/TLSに関するガイドラインです。特にインフラに馴染みのない人は大変勉強になるかと思います。「Webシステム/Webアプリケーションセキュリティ要件書」OWASP Japan
経済産業省に掲載されている、OWASP Japanが発行したチェックシートです。中身はさることながら「経済産業省」のブランドは対外的に説明しやすいため非常によいと思います。「ソフトウェア出荷判定セキュリティ基準チェックリスト」CSAJ
CSAJ (一般社団法人コンピュータソフトウェア協会) が策定したチェックリストです。「とある診断員とAWS」 洲崎 俊氏
AWSで気をつけるべきポイントがとてもよくまとまっていて参考になります。「フリーでやろうぜ！セキュリティチェック」洲崎 俊氏、小河 哲之氏、亀田 勇歩氏
自社でのセキュリティテストに慣れていない人にはいいとっかかりになります。「IPA テクニカルウォッチ「ウェブサイトにおける脆弱性検査手法(ウェブアプリケーション検査編)」」IPA
IPAによるアプリケーション脆弱性診断ツールの調査結果がまとまっています。ツール選びに非常に参考になります。「Rails セキュリティガイド」原著者
Railsガイドのセキュリティパートです。やさしく書かれているのでわかりやすいです。「Ruby on Rails Cheatsheet」OWASP
OWASPの資料です。「Railsセキュリティガイド」とあわせて読むとより理解が深まると思います。
1.3. 学習
脆弱性は作り込まないことが一番重要です。実装前に事前学習を行います。デベロッパー全員で学習したあと、簡易な脅威モデリングを行います。
ポイント
- 脅威モデリングは脆弱性を攻撃者視点で洗い出せる以外に、全員のセキュリティに対する意識を高めることができるのでオススメ。
- セキュリティリーダーが先行して学習し、各メンバーの作業担当に即したコンテンツを絞り込んであげると効率的です。
- MUO (マークアップオリエンテッドな) フロントエンドデベロッパーは普段の仕事の要件特性上、セキュリティに関しては感度が低くなりがちなので、特に入念なフォローを行ってあげた方がよいです。
1.4. 社内診断準備
セキュリティリーダーが以下の準備をします。
- 社内診断用チェックシートを整理チェックシートとしてまとまっていない書籍などはオリジナルチェックシートを作成します。
社内診断で利用する診断ツールを選定し使い方をマスターするエクメルンでは以下のツールを利用しました。
「Qualys SSL Labs」 Qualys, Inc
フリーでSSLを診断してくれるサイトです。「Web Server Security Test」 High-Tech Bridge SA
フリーでCSPを診断してくれるサイトです。 (SSL診断もあります)「AWS Trusted Advisor」
AWSのサービスの一つで、AWSの設定や運用周りをチェックしてくれます。「AWS Inspector」 AWSのサービスの一つで、EC2のOSやミドルウェアレベルをチェックしてくれます。
- 「OWASP ZAP」
OWASPのフリーのアプリケーション脆弱性診断ツールです。前述の「IPA テクニカルウォッチ「ウェブサイトにおける脆弱性検査手法(ウェブアプリケーション検査編)」」の比較表をみて選定しました。
AWSへの侵入テスト申請却下されて慌てることがないように少なくとも2週間前には申請しておきます。
ポイント
- 申請は英語です。
- CloudFrontを経由しないようにテストする必要があります。
- EC2とRDSへのテストが目的であればALBのWAFを経由したテストでもOKです。
1.5. 社内診断
チェックシートを用いた確認と、ツールによる診断を行います。
ポイント
- アプリケーション診断では、データの破壊を試みるテストやサーバー上で一時的にプログラムを強制的に編集せざるを得ないケース (例えば試行回数の制限解除など) もあるため、基本的にはステージング環境を利用します。
- アプリケーション診断では、プラグインが何も入っていないクリーンなFireFoxがオススメです。(FireFoxはXSSAuditorが実装されていないためです)
- ユーザビリティとトレードオフとなる悩ましいケースは、他の有名サービスを調査し検討してみるのも手です。
- 診断結果とその対応履歴は必ずドキュメントに残します。次回チェック時に参考になります。また万が一法廷での争いとなった場合に自分たちの身を守ることにつながるかもしれません。
1.6. 社外診断
外部のセキュリティ診断会社によるアプリケーション脆弱性診断を行います。
ポイント
- 自分たちのサービスローンチ日と、先方のリソース状況の兼ね合いがありますので、早め早めに調整した方がよいです。
- 社内診断と同じく診断結果とその対応履歴は必ずドキュメントに残します。
1.7. 情報公開
コスト構造などの面から個別のセキュリティチェックの依頼を受けない方針とする場合、セキュリティへの取り組みをきちんと公開します。
エクメルンでの例
サイボウズ社での例
1.8. 運用改善
問い合わせ対応のために本番環境にアクセスし調査を行なうことがあったのですが、操作ミスによってデータの消失や、漏洩が発生しないとも限りません。そのため、問い合わせでよく参照する情報を管理画面に参照可能にしています。その結果、リスクが下がったことと、非エンジニアでも問い合わせ対応を行えるようになりました。