セキュリティについてのセオリー:マイクロサービスアーキテクチャ(6)

個人開発したアプリの宣伝
目的地が設定できる手帳のような使い心地のTODOアプリを公開しています。
Todo with Location

Todo with Location

  • Yoshiko Ichikawa
  • Productivity
  • Free

スポンサードリンク

第9章 セキュリティ

基本的にはマイクロサービスに関係なく、複数のサーバ運用しているサービスのセキュリティに対して当てはまることが解説されている。

認証・認可の課題

前提として全員がシステムごとに異なるIDとパスワードでsign inを行うという作業はしたくない。

前職ではLDAPのようなディレクトリサービスで解決してた。本書でもそういった手法での解決を案内している。

また、認証を行うゲートウェイを用意して、各サービスにはsign inの機能を引き剥がすという案もあるが、それはそれで問題が多い。

  • 下流サービスに認証、認可の情報をどのように渡すか?結局はその情報を基に個々のマイクロサービスが判断する実装が必要となる。
  • 各サービスの振る舞いに関する「認可情報」がゲートウェイで管理されると、個のサービスから見た時にその情報が密結合となってしまう。
  • ゲートウェイがクリティカルパスになる。

認証ゲートウェイを立てる場合は過度な認可情報を持たせないように注意しよう。

サービス間の安全な通信について

  • 基本はSSLと思っておけば良い。
  • 境界内におけるサービスを敢えて外部に配置する必要はない。
  • 個のサービスでアイデンティティプロバイダとハンドシェイクする。
  • クライアント証明書
  • AWSで利用されているようなHMACでリクエスト署名する。
  • APIキーでの署名

個人的にはクライアント証明書がいいと思った。

また、認証された利用者が認可されたサービスを利用する場合でも、パラメータの書き換え等で仕様上見せちゃなダメな情報にアクセスされるケースもある。(他人の注文情報が流出する等)

データの保管方法

機密なデータに対しては暗号化するにこしたことはない。

鍵の管理をローカル内で行うと意味がないので工夫する。

  • セキュリティアプライアンスで暗号化、復号を行う
  • 鍵管理システムを利用する

多層防衛

  • ファイアウォール
  • IDS, IPS
  • ネットワークセグメントの分離
  • OS

この辺りはマイクロサービスに限ったことではないよね。

実施例

認証、データ保護、防衛は各々のサービスが提供する情報の質で柔軟に対応すれば良い。

例えば、一般公開されている情報の検索サービスなんかは、厳密なことはしなくてよくて、APIキーで利用者を特定できればそれで良い。のような手法例が紹介されている。