ガバメントクラウドは、クラウドの中でもシステムの土台の方へのサービス（IaaS，PaaS）に関する認定で、政府情報システムのためのセキュリティ評価制度（ISMAP）に基づき高いレベルのセキュリティ対策が必要になる。しかし、ガバメントクラウド上で動く（SaaSを含む）アプリケーションに関しては、特段の監査は行われない。
地方自治体向けのアプリケーションのASP向けの規制案「ガバメントクラウドにおけるSaaS（公共SaaS）について（案）」が出て来て、不十分なセキュリティ対策ではないかと言う声が上がっている。ASPは事業者で、SaaSはアプリケーションを提供するサービス。対策不十分と言うだけではなく、何か勘違いをしている可能性がある。
1. モダンなクラウド利用だと安全と言いたい？
話題になっていた部分は以下。
3.1. ガバメントクラウドにおけるSaaS①公共SaaS公共 SaaS とは、ガバメントクラウド上で、業務アプリケーションを開発し、SaaS の形態でサービスを提供する類型である。
業務は、公共・準公共分野に限定され、業務アプリケーションの標準仕様は当該業務の制度官庁等によって管理される。アプリケーションの開発にあたっては、ガバメントクラウドが要求するモダン化されたアプリケーションを開発し、公共 SaaS の要件（後述）を満たす必要がある。SaaS の運営主体は、府省庁（国営）と民間事業者（民営）を想定しており、業務システム相当に加え、特定機能（粒度の大きいマイクロサービス）を提供する共通サービスも対象とする。
ガバメントクラウドは ISMAP 取得済のクラウドサービス（IaaS、PaaS）であり、デジタル庁において統一的なセキュリティ統制がとられていることから、ガバメントクラウドの開発環境で整備された公共SaaS については当該 SaaS が ISMAP を取得していなくともセキュリティ上のリスクが低いことをデジタル庁として担保することで、行政機関等が当該公共 SaaS を採用しやすくできないかを検討中。
段落と段落のつながりに不明瞭な面があるのだが、モダンなクラウド利用だとセキュリティ上のリスクが十分に低いと解釈できる。しかし、この発想はかなり危ない。
2. モダンなクラウド利用でも、減らないタイプのリスク
WordPressと言うお化けアプリケーションがある。実行可能なプログラムのためのディスク領域を書き換えることで、バージョンアップやプラグインの追加を可能にしている。便利なのだが、危険な仕様だ。セキュリティーホールのあるプラグインが流通し、外部からウェブシェルが実行可能領域に書き込まれ、アプリケーションが出来ることは何でもできるようになる攻撃が多発したことがある。
モダンなクラウド利用でも、こういうアプリケーションの問題に基づく攻撃を防げない。実際、WordPressはコンテナ化*1可能であり、オブジェクトストレージやマネージドサーバーを使えるようにできるから、モダンなクラウド利用が可能だ。ウェブシェルが揮発領域（エフェメラルストレージ）に書かれるとしても、攻撃者がデータベースに侵入したり、ログイン画面に利用者のパスワードを盗む仕掛けをしたりする事はできる。
ISMAPが無駄と言うことはない。過去事例では権限昇格攻撃によりサーバーが乗っ取られることもあったが、ISMAP監査を受けたクラウド事業者のサーバーやOSに既知の脆弱性は無いであろうし、サーバーやOSのログやファイルは監視しているはずだ。しかし、クラウド利用者のアプリケーションのファイルの変更などは監視してくれない。異常なトラフィックの検知は出来るかも知れないが、分かったときには後の祭りである。
オンプレミス環境では、外部に露出しないOSやDBMSのセキュリティ・ホールは利用が難しく*2、露出しているウェブサーバーも大きな問題は少なかった*3。攻撃者が付け込みやすいのは、外部に露出しているWordPressやJoomla!といったお化けアプリケーションや、それらを動かすプログラミング言語PHPのセキュリティーホールだ。なお、モダンなクラウド利用の中でもFaaSであれば、クラウド事業者がプログラミング言語の実行環境の面倒も見てくれるが、そこまで縛るとアプリケーション開発の自由度が大きく落ちる。
3. クラシカルな対策
モダンなクラウド化でリスクが増すわけではないが、構造的に完全と思わせそうな記述は避けて頂きたい。
オンプレミスもしくは前時代のクラウドでは、アプリケーションに危険な機能を持たせないようにしたり、セキュリティーホールになりかねない書きかたを禁じたり*4、バージョンアップで互換性が失われるようなプログラミング言語を避けたり、サーバー上にも不正侵入防止システム（IPS）もしくは侵入検知システム(IDS)を仕掛けたりしている。モダンなクラウドでIPSとIDSの導入は躊躇われるかも知れないが、同様の対策は推奨して頂きたい*5。
なお、思いついた対策をすべて同時に実行する必要はなく、危険なWordPressやJoomla!を、もしものときの被害を抑制できるように計画することもできる*6。機密情報がない情報公開用途であれば、改ざん検知で十分と言うような算段は働かせてもよい。
*1語弊があるが、OSの名前空間を使ったアプリケーション隔離/仮想化技術のDockerの隔離領域をコンテナと言う。本当はファイルの状態がDockerイメージで、ロードするとDockerコンテナ･･･と言ったりするが、コンテナと言っておけば文脈で分かってもらえるハズ。
*2外部に露出しているbind，sendmail，wu-ftpdが頻繁にクラックされていた時代があるが、より安全な設計の代替ソフトウェアの普及で随分と減ったようだ。
*3ただし、特定モジュール（i.e. mod_rewrite）が何回も穴を出していた。
*4「IPAセキュア・プログラミング講座」あたりが参考になるはず（未読）。なお、なぜか一般ユーザーの入力文字列をサニタイズしないで表示し、XSSの脆弱性がおきる事件が多発していた。他にSQLを書くときにプレースホルダーを使っていれば･･･と言う事件も多々あった。まぁ、プレースホルダーの実装がアレで使っていても･･･と言う話も聞いたようなことがあるが。
*5ASP事業者もアホではないが、自社がつくってきたソフトウェア/サービスの提供ではなく、事実上の受託開発になるような場合は、忙しくて油断する可能性が増す。
*6先日、AppArmorとOSSECを利用するJoomla!インストールの手順を書いてみたが、そう大変と言うわけでもなかった。サーバーの台数がある状態でこのやり方だと破綻すると思うが。
0 コメント:
コメントを投稿