いくらセキュリティに拘っても安全にならない場合があります。その代表例はソフトウェアの開発環境です。そもそもセキュアにすることが無理な場合、別の対策を取る必要があります。
細かいセキュリティ対策を実施するより、本質を捉えて全体対策を行う方がより安全になる場合があります。開発環境はその代表例です。
ソフトウェア開発の現場
今時のソフトウェア開発はプロプライエタリなソフトウェアでさえ多くのオープンソースソフトウェアを利用しています。オープンソースソフトウェアを利用していない場合でも、多くのライブラリやミドルウェアを利用しています。
ソーシャルコーディングも当たり前になり、ソフトウェアの開発現場を一般ユーザーの環境に置き換えると
ユーザーがほぼ自由にアプリをインストールして実行している状態
と変わりません。OSや言語、フレームワークなどは勿論、多数利用されているライブラリなど（composerやgemのライブラリなどに限らず、.so/.dllなども含めて）もどんどん更新されています。このリスクは認識されており”全てのソフトウェアは利用する前にその安全性を確認すべき”とするセキュリティ指針もあります。
全てのソフトウェアを確認することは可能か？
全てのソフトウェアの安全性を事前に確認するのはセキュリティ対策として優れています。しかし、これを実際の開発現場で実施することは可能でしょうか？
- オープンソースならソースコードを解析する
- 次善の策としてブラックボックステストを実施する
ソースコードがないソフトウェアの場合、逆アセンブルして解析する、という方法もあります。しかし、現実的にはブラックボックステストしか方法がないでしょう。
これらの安全性確認を実施することは技術的には可能です。しかし、ビジネス的にこうした安全性確認を行い徹底的に開発環境で利用するソフトウェアの安全性確認をすることは、普通はコスト的に許されません。これを実施するとソフトウェア開発が本業なのか、セキュリティ研究調査が本業なのか、わからない状態になるからです。
仮に実施しようとしてもUNIXに入れられたバックドアでさえ本人が告白するまで見つからなかったように、見つからずに検査をすり抜ける可能性があります。
参考：
脆弱性や攻撃用コードがないを保証することは実質的に無理です。
できない場合、別の対策を実施する
開発環境のセキュリティ対策に限りませんが、”脆弱性や攻撃コードはある”を前提とし”脆弱性があっても困らない状態”にする対策の方が現実的かつ効果的です。（脆弱性やマルウェアをどんどん入れてよいという意味ではなく、完全に無くす事は不可能とする前提に立つ。しかし、”できる限り入れない”対策が先）
数え切れない新しいソフトウェアのインストール、バージョンアップ、古いソフトウェアの維持、リスクの高い開発ツールを利用する開発環境を比較的安全に利用するには、開発環境を他の環境と分離します。
最も確実な方法は物理的に分離する方法です。開発環境で利用するネットワーク、デバイス（PCやモバイルデバイス）は分離し、破壊されたり、盗まれたりすると困るデータは一切置かないようにします。
しかし、物理的に分離する方法は通常の業務用の環境、開発用の環境を別々に設置・維持しなければならないので大きなコストが必要です。VLANと仮想マシン（仮装環境）で分離する方法が現実的です。
開発環境の分離の方法
詳しい方法を書くとかなり長くなるので概要のみ紹介します。
- ネットワークを分離する。（攻撃可能面分析を行い、攻撃可能面を可能な限り小さくし、残ったリスクが許容範囲内のリスクであることを保証）
- 盗まれると困るデータは一切置かない（実際に業務に利用するデータを開発用データとしない）
- 破壊されると困るデータは一切置かない（＝破壊されても構わないようにする。ソースコードやドキュメント、ツール類などはバージョン管理システムを導入し、バージョン管理システムのセキュリティを強固にする）
- 異常または攻撃の可能性がある動作を検出する。（NIDSを使い意図しないネットワークアクセスやMACアドレス／IPアドレスの利用などを検出する）
それぞれの対策にはそれなりのコスト（労力や設備）が必要ですが、大量のソフトウェアの安全性を全て確実にチェックすることに比べ、遥かに少ないコストで実現でき、それなりの安全性を確保できます。
開発ネットワークの分離
ポイントだけ紹介します。VLANと仮装環境を使った確実な分離方法の紹介は長くなるので割愛します。今時はWebを利用しないで開発することはありません。開発ネットワークの安全性を確保する場合に問題になるのは
- インターネットからダウンロードしたり、購入したソフトウェアの安全性
- 自らが開発したテストコードやツール類の安全性
これらのどちらもセキュリティをあまり考慮していなかったり、全く考慮していないソフトウェアは普通にあります。これらの中には攻撃する目的で記述された物が含まれる可能性もあります。（自らの組織内に攻撃者がいることも想定しなければなりませんが、話を単純にするためここでは考えません）
もっとも可能性が高い攻撃方法の一つはXSSやCSRFなどの「クロスサイト攻撃」です。クロスサイト攻撃には罠ページや罠メールが必要です。
罠ページの対策 – クロスサイト攻撃防止＆検知
クロスサイト攻撃に利用する罠ページ対策は比較的簡単です。開発環境からのWebアクセスには開発専用に限定したホワイトリストを使ったプロキシを利用することでかなりリスクを緩和できます。プロキシにはローカルIPアドレス（ループバック・プライベードなど、IPv4とIPv6の両方）へのアクセスを必ず禁止するようにします。標準でないHTTP/HTTPSポートへのアクセスもリスクが高いので標準ポートのみ（80と443）利用できるようにします。
参考：ローカルネットワークへのクロスサイト攻撃はプロキシで防御／検出可能
ソーシャルコーディングを行うにはgithubなどのサービスへのアクセスを許可する必要があり、それらのWebサイトに罠ページが設置される可能性もあります。許可されたサイトであっても、細かくホワイトリストでURLを制御すればリスクを軽減できます。あまり細かくURLを制御すると利便性が低下するので安全性と利便性のバランスを考えて選択する必要があります。
ローカルネットワークへのアクセス
ローカルIPアドレスや非標準ポートへのアクセスを禁止すると開発ができないばです。これらにアクセスするためには「ローカル専用のプロキシとブラウザ」を利用します。Firefoxならプロファイル毎に異なるプロキシを設定可能です。プロファイルレベルで分離しても、安全性はそれなり保てます。
インターネットへのアクセス
インターネットへのアクセスが極端に制限されていると開発に支障があります。利便性と安全性のバランスを考えると、インターネットにアクセスするブラウザは別セグメントのネットワークに接続した仮想環境を利用する方法が妥当でしょう。しっかり分離していれば、大抵の問題（攻撃）は影響を与えることがありません。
まとめ
開発環境に脆弱なアプリ/ツールがあると困る環境の場合、環境自体に改善の余地があります。
ざっと最小限の必要事項を説明しました。足りないモノやもっと良い方法もありますが、スタート地点としては十分だと思います。
ネットワークを分離せず、自由に使えるようにすると便利ですが、その分リスクが増えます。開発環境は適切に分離し、開発環境で何らかの問題があっても致命的な問題にならないようシステム的に対策する方が良いです。今ならあまりコストをかけずに分離できます。
そもそも攻撃されない/できないようにする方が良いので、可能な限り脆弱性のない状態にする方が良いのは言うまでもありません。しかし、神経質に開発環境のセキュリティをチェックしなければならない状態から、緩く管理していても攻撃を防止／直ぐ検知できる状態の方がバランスがよいセキュリティ対策だと思います。
Leave a Comment