この記事はNTTテクノクロス Advent Calendar 2020の5日目の記事です。
NTTテクノクロス アソシエイトエバンジェリスト 武井 滋紀です。
なかなか耳慣れない役職なのですが、社内には高度専門人材のキャリアプラン(制度についてはこちら)があり、自分はそのエバンジェリストのキャリアプラン(紹介はこちら)に位置しています。元々は開発のエンジニアでスタートして気がつけばセキュリティの高度専門人材のキャリアにいます。
本日は5日目ということで、普段はセキュリティ組織体制の作り方などのコンサルタントや各種講演を行っていますが、開発のエンジニアからスタートしているので、今日はそのあたりの関係性からお話をしようと思います。
はじめに
本日の中身は以下となっています。
- セキュリティの対策ってどうやるの？
- 開発におけるセキュリティの検討のタイミングは早く
- セキュリティの対策は機能として実装する
最初の部分は一般的なセキュリティの対策はどうするかの話です。その辺はいいから、どうするの？という方は2つ目まで飛ばして頂ければと思います。
せっかくなのでセキュリティの対策の全体像から読んでみたい、という方は最初からどうぞお願いします。
セキュリティの対策ってどうやるの？
ここでは、一般的にセキュリティの対策を決めるまでの流れを紹介します。何を守るべきか決めて、優先度を付けよう、という内容です。
「セキュリティの対策をやって」と言われたり、仕様書などに「安全であること」しか書かれてなく具体的にどうしたらよいのか困った経験の方も多いかと思います。
この、具体的にどこに対して何をするかがよくわからないこと、常に新しい攻撃手法が出続けることが、対策をする側にとって考えることを難しくしてしまっていると思います。
とにかくなんでもやろうとすると、やるべきことのリストが増えるだけで始める前に途方に暮れたりコストの面が問題になることもあります。
開発だけの話ではなく、セキュリティの対策をどうするのかを全体から考えると以下のようになります。
- 守りたいものが何かを決める
- もし、それが被害に遭ったらどれくらいの影響があるかを知る
- 守りたいものと被害に遭った場合の影響度から、対策をする優先度を決める
影響を考える場合には、そのシステムやソフトウェア、サービスを持つ部門だけではなく、広報や法務、総務など幅広い部門にも確認することもポイントです。最近ではセキュリティの事故はビジネスにも大きな影響を及ぼします。ビジネスにどんな影響があるかは自分たち以外の幅広い部署などに確認しておきたいところです。
影響度の測り方について「リスク値」として算出する方法があります。IPAからのガイドラインの中にリスクの評価を行うための付録、「付録7：リスク分析シート」も公開されています。
IPA 中小企業の情報セキュリティ対策ガイドライン
その他にも会社や組織にセキュリティの「ポリシー」やセキュリティの「管理策」と呼ばれるものがあれば、それを参考にセキュリティの対策として何をしなければならないか考えることもできます。
このような流れで段々と何をすべきかを具体的することで、やるべきことに優先度をつけることができるようになります。やるべきことが決まれば、各種のガイドラインを参考にどんな対策をすればよいかも考えることができるようになります。
最近だと各種ガイドラインも整理されつつあり、どのタイミングでどれを見れば良いかわかるようにもなってきています。自分の状況を整理し、必要なタイミングでガイドラインを活用すると良いかと思います。いくつかのガイドラインの例を以下にあげます。
IPA 脆弱性対策コンテンツリファレンス
OWASP Top 10
OWASP Cheat Sheet Series
OWASP Application Security Verification Standard (ASVS)
何をすべきかが見えてくると、残る危険性は理解した上でセキュリティの対策はしない、見送るという部分の決定もできることになります。
ただし、「残る危険性を理解した上で」というのが重要です。後になって何か起きた時に「なぜそこは対策しなかったんですか？」と聞かれることになります。どんな検討の結果なのか、どのような想定でその対策はしないと決めたのかは記録として残しておく必要があります。
対策をしなかった部分は、定期的に見直しをして優先度が上がれば対策をすることになります。一度決めたら終わりではなく、継続的に状況の変化に対応してセキュリティを考える必要があります。
ここまでが一般的なセキュリティ対策をどうするの？という流れからのお話でした。
開発におけるセキュリティの検討のタイミングは早く
それでは、実際に何か開発するときのセキュリティはどうしよう？というお話です。なるべく早く、検討段階からセキュリティの対策を決めておこう、というお話です。
最近は、開発の最後にセキュリティの脆弱性がないか診断を行うところも多くなっています。もう少し踏み込んで、実装段階のソースコードに脆弱性がないかを診断することもあります。
開発をされている方は実感されていると思いますが、開発の後の段階になってから何か機能追加や修正をしようとするほどコストがかかります。
セキュリティの対策も同様で、最後の最後、リリース直前にセキュリティの不備が見つかるとその対策や修正をするために多大なコストがかかる場合もあります。
サービスを始めてしまった後でなんとかしようとしたが、これからだとセキュリティの対策にコストがかかりすぎるのでサービス自体をやめる、という判断になることもあります。
なるべく早い段階、仕様を決める際や設計の段階で、セキュリティをどうするか？を考えておくことが重要になります。
この段階だと、先ほどのようにこのシステムでは何を守るべきなのか、何か起きた場合の影響をどこまで見ておくか、という考え方からセキュリティの対策として何をするかの検討ができます。
IPAやOWASPからセキュリティの要件のガイドラインも出ており、参考にすることもできます。
OWASP Japan Webシステム/Webアプリケーションセキュリティ要件書
他の検討の方法として、消極的ではありますが開発の最終段階でどのようなセキュリティに関連した試験、脆弱性の診断をするかを参考にすることもできます。
最近は開発した自分のシステムやアプリケーションは他のサービスと連携していることもあります。その場合は何か起きた場合の影響について自分のところだけではなく連携している他のサービスも含めて考えておく必要があります。
セキュリティで何か起きた場合の全てを想定や想像をするのは難しいので、同業他社や似たシステムやアプリケーション、サービスでのセキュリティの事故・障害のニュースや報告を参考にすることもできます。
過去に起こったということは同じような手口で狙われることもある、ということです。狙う側からすると同じ手口で成功するのであればそれだけ攻撃のハードルが低くなります。
早い段階で何を守るべきなのか、何が起きたら困るのかをはっきりとさせることでその後の検討が進めやすくなります。
セキュリティの対策は機能として実装する
それでは実際の設計や実装でのお話です。セキュリティの対策でも機能として実装すべきものは機能として見積もりや実装をしましょう、というお話です。
実際にシステムやアプリケーションの検討段階では、セキュリティの要件は非機能要件として機能ではないが考慮すべきこと、と考えられることが多いかと思います。
しかしながら、そのセキュリティの要件を対策として実現するためには、機能として実装することになります。非機能要件のままでは機能ではないと考えられてしまうのですが、必要なセキュリティの対策は機能として見積もり、実装をする必要があります。
例えばよくある脆弱性に、クロスサイトスクリプティング(XSS : Cross Site Scripting)やSQLインジェクションと呼ばれるものがあります。
いずれの脆弱性についても、Webのフォームやユーザーから入力されたデータをそのままプログラムの中で利用してしまうことで起こります。
対策の方針としては以下があります(色々なやり方があるので一例です)。
- 入力されたデータが仕様の範囲内であるか、想定内であるかチェックをする
- 入力されたデータを利用する際、例えば画面に表示する前や、SQLに組み立てる際にそのまま利用しないようにする
例えば、これを機能として実装するならば以下となります(色々なやり方があるので一例です)。
- 入力された値をチェックする機能を実装する
- データを利用する前に事前に用意した安全な値に置き換える機能を実装する
最近のフレームワークやライブラリでは、元々セキュリティの機能も持っているものもあります。必要な機能の中で利用できるものは利用しましょう。
実際にどうすべきかについてもガイドラインの中で詳細に示されています。
IPA 安全なウェブサイトの作り方
このようにセキュリティの対策を実装するならばそれなりに機能として実装する必要があります。仕様の段階からも何を受け付ける、何を受け付けない、といったことも含めて、何をすべきか、どうすべきかを明らかにしておく必要があります。
おわりに
作ったらセキュリティの対策は終わり、ではなく動かし始めてみんなが使い始めてからが本番です。
すでに分かっている脆弱性は作りこまない、もし新しい攻撃が発見されてもすぐに直してサービスを再開することの継続です。
OSやライブラリ、フレームワークの脆弱性によってバージョンアップに対応することも多くなっています。リリースまでの時間を短くするためにも、セキュリティの試験も含めた試験の自動化を行っている開発者の方も多いかと思います。
DevOpsについてもCI/CDのなかでセキュリティの試験も組み込み、セキュリティを確保しながら開発を進めることもできるようになってきています。
新しい機能の追加や運用をやりやすくすることも必要ですが、セキュリティ面でも気にしながら開発をして平和な世の中になって欲しいと願います。ハッピーメリークリスマス！
明日は@kn-tomさんのPostgreSQL関連のお話です！明日もNTTテクノクロス Advent Calendar 2020をお楽しみに！
あ、会社の話をあんまり書いてなかったですね。NTTテクノクロスではセキュリティの要件がガイドラインとして整理され、ソースコードの診断やWebアプリの脆弱性診断が社内でできるようになっています。