0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

前置き

今まで触れてきた事例で、あまりセキュリティアーキテクチャを変えるというケースを目にすることもなければ、わたしが運営をしている脅威モデリング、セキュリティエンジニアの文脈でソフトウェアアーキテクチャの設計原則が触れられることはほぼありませんでした。

どうやら、まだセキュリティアーキテクチャの文脈に対して、変更容易性やら再利用性などの普及が未成熟とのことなので、今回はそれに関する記事を書きます。

セキュリティ文脈における変更容易性

確かに、セキュリティ基盤全体を一度に「総入れ替え」するような大規模なプロジェクトは、コストやリスクが非常に高いため、頻繁には行われません。

しかし、実際には部分的なセキュリティコンポーネントの入れ替えや、アーキテクチャ思想の進化は絶えず起きています。

変更を促す主な要因

近年、特に以下のような要因で、セキュリティコンポーネントの入れ替えや追加が活発に行われています。

クラウド化と技術の進化 ☁️

これが最も大きな要因です。
オンプレミス環境からAWSやGoogle Cloudのようなクラウドへ移行する際に、ファイアウォールや認証基盤などをクラウドネイティブなサービス(AWS WAF, IAMなど)に入れ替えるケースは非常に多いです。

新しい脅威への対応 👾

ランサムウェアやAIを使ったサイバー攻撃など、新しい脅威が登場するたびに、それに対応するための新しいセキュリティ製品(EDR, XDRなど)が導入されます。

ツールの世代交代とコスト最適化 💸

より高性能でコストパフォーマンスの良いツールが登場すれば、古いツールから乗り換えることがあります。
例えば、旧来のログ監視ツールから、DatadogやSplunkのような最新の観測プラットフォームへの移行などがこれにあたります。

新しい法規制やコンプライアンス 📜

GDPR(EU一般データ保護規則)のような新しい規制が始まると、その要件を満たすために新たな暗号化コンポーネントやアクセス管理の仕組みを導入する必要があります。

ここまでのまとめ

このように、昨今のセキュリティアーキテクチャは一度作ったら終わりではなく、ビジネスや外部環境の変化に対応して常に進化し続けるものなのです。
そのため、変更しやすいように関心を分離しておく設計思想が、後々非常に重要になってきます。

だからこそ、

セキュリティ文脈でもSOLIDやコンポーネント原則を含む設計原則を抑えておく必要があるんです。

セキュリティアーキテクチャの段階的進化

アプリケーションアーキテクチャの進化と、セキュリティアーキテクチャの進化は、
互いに両輪で進化していきます。

アプリケーションコードの方は進化しているのに、セキュリティアーキテクチャは変わっていないなんてことはあってはならんことです。

アプリケーションの関心事の分離が進むにつれて、セキュリティの関心事も同じ粒度で
分離・専門化していく、という自然な流れです。

1. モノリスと中央集権セキュリティ

最初は、アプリケーション全体を1つの「城」のように捉え、その入り口に大きな「城門」としてモノリシックなセキュリティコンポーネントを置きます。

全ての認証・認可をそこで一元管理する、非常にシンプルで分かりやすい構成です。

ファイル名

2. モジュラーモノリスとドメインごとのセキュリティ

ビジネスが拡大し、モノリス内部が論理的なドメイン(モジュール)に分割され、モジュラーモノリスへと進化すると、セキュリティ要件も細分化されます。

「この機能(ドメインA)は管理者しか使えない」

「あの機能(ドメインB)は一般ユーザーでも使える」

といった具合です。

image.png

ここで、各モジュール内の横断的関心事として、Spring Securityのようなフレームワークの機能(アノテーションなど)を使い、ドメインごとにきめ細かなアクセス制御を実装するようになります。

3. マイクロサービスとサービスメッシュ

そして、マイクロサービスアーキテクチャに移行すると、問題はさらに複雑かつ高度になります。

サービス内部のセキュリティ

各サービスが、モジュラーモノリスの各モジュールのように、自身の責務範囲でセキュリティを実装します。

サービス間の通信セキュリティ

これが新たに生まれる大きな課題です。
「サービスAはサービスBを呼び出して良いか?」「サービス間の通信は暗号化されているか?」といった、サービス同士の交通整理が必要になります。

ここで「サービスメッシュ」(IstioやLinkerdなど)が、この課題を解決するための必須技術として登場します。

サービスメッシュは、個々のマイクロサービスのビジネスロジックには手を加えず、インフラ層で以下のようなセキュリティポリシーを一元的に管理・強制します。

通信の暗号化 (mTLS):全てのサービス間通信を自動で暗号化します。

アクセス制御:「どのサービスがどのサービスを呼び出せるか」といったポリシーを定義します。

可観測性:通信ログやトレースを統一的に収集し、監査や障害調査を容易にします。

このように、アーキテクチャが進化するにつれて、セキュリティの実装箇所や考え方も、
中央集権型 🏰 → ドメイン分散型 🧱 → ネットワーク分散型 🌐 へと進化していきます。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?