マイクロサービスとセキュリティ

私たちは皆、感染症が広がるのを予防するために手を洗うことの重要性を知っているが、アプリケーションセキュリティとなるとしばしば後付けで処置しようと試みる。開発ワークフローにテストを加える方法については既に学んでいるが、セキュリティに関しては誰かが来て後で修正してくれるとしばしば決めてかかってしまう。Sam Newman氏はロンドンのMicroservices Conferenceの基調講演において、マイクロサービスの文脈でのセキュリティに関してこう主張した。

Atomistに勤務するNewman氏によれば、マイクロサービスはヘキサゴナルアーキテクチャにより形成され、それぞれのビジネス責務に対応した名前付けがされている。それらは自律的でもあり、この自律性は第一に独立した配置可能性を提供することを特に付け加えた。

モノリシックシステムでは、一つの区画もしくは境界を持ち、防護すべきデータベースは一つであることがしばしばある。もしこのようなシステムに誰かがセキュリティ違反や攻撃で侵入したら、おそらくシステム内の全ては攻撃者からアクセス可能となるだろう。マイクロサービスに基づいたシステムで、適切なセキュリティ対策がされていれば、攻撃者が取得可能な権限や、あるサービスに侵入する一回の攻撃においてアクセス可能なデータ量を制限することができる。しかし、これと引き換えに、攻撃可能な界面は増加し、攻撃可能なサーバは増えることになる。単一のモノリシックプロセス内のメソッド呼び出しは今や露出したAPIに対するネットワーク呼び出しとなる。多くのサーバが存在し、手動のパッチ適用を行う状況では、サーバにパッチを適用し忘れるリスクは増大する。

脆弱性の実証コードや潜在的な攻撃ベクタを確認した時、私たちは合理的な思考を行わないこともしばしばである。一歩引いてこのことを全体感を持って観るべきであるが、一般に私たちはこれを受けてこの脆弱性の使用を防止するために改良を行ってしまう。これはシステム内に脆弱性を広く開きっぱなしにしたまま、誤った箇所に資金を投入していることを意味する。

そうではなく、脅威モデル手法を採用し、予防するためにどこにエネルギーを使うかに関して合理的な思考を行うための方法についてのプロセスを分解するべきである。Bruce Schneider氏が書いたAttack treesと、Microsoftのセキュリティ開発ライフサイクルはstrideとdread脅威モデリングの技術を用いた2つの例である。

セキュリティを強化するための単純な第一歩は、内部通信も含めたどの通信にもHTTPSを使用することである。こうすることで、ペイロードが改ざんされておらず、サーバが正当なものであることを保証することができる。Let’s encryptは無料で、自動化された認証局であり、公開webで使用するhttps証明書の取得に関する手間を軽減することに挑戦している。Newman氏は、彼らの最も重要な機能は自動化されている点だとした。サーバ側でクライアントを検証するためにクライアント証明書が必要がであるが、この行為はしばしば管理の負担が重いものである。

Newan氏によると、Dockerは偉大な技術であるが、多くの公式イメージや信用されているイメージには致命的な脆弱性があり、これらのイメージのどれかを使用した時には同時に脆弱性も抱え込むことになる。そのため、彼は脆弱性の静的解析を支援するclairのようなツールの使用や、頻繁にパッチを適用することを強く勧めている。

検知、もしくは何か悪いことが発生したことを知ることは、新しい攻撃を防止するために価値を生む可能性があるが、稼働中のサーバの新しい脆弱性を発見することも重要である。しばしば攻撃はログに痕跡を残す。中央の1箇所から全てのログにアクセスできるようにすることは、セキュリティとアプリケーション開発の両面の観点から行うべき重要な第一歩であるとNewman氏は述べた。

予防と検知に加え、Newman氏は反応と復旧に関する検討の重要性についても触れた。セキュリティ違反にどう反応し、どうやって顧客に課題を伝達するだろうか？システムが破壊されたらどう復旧するだろうか？データが多数のマイクロサービスに分散している時はバックアップからの復旧は著しく困難になる。

ロンドンで行われる来年のMicroservices Conferenceは2017年11月6-7日に開催される計画である。