4つの要素をマスターする: アプリ アーキテクチャを強化し、アプリと API のセキュリティを向上します

1) グローバルサイト共有サービス層

パブリック クラウド インフラストラクチャを利用する場合でも、プライベート クラウド インフラストラクチャを利用する場合でも、Webapplicationsと API のセキュリティを確保することが重要です。

まず、マルチクラウドおよび分散環境に展開された Web アプリと API を保護する方法について考えてみましょう。 ここでは、ドメイン ネーム サーバー (DNS)、コンテンツ配信ネットワーク (CDN)、WAAP (Web アプリおよび API 保護)、不正使用対策を実装して、Web/API 攻撃、脅威キャンペーン、ボット、高度な詐欺に対する安全策で防御を強化し、堅牢な保護を確保します。

そうすることで、異機種混在のマルチクラウド環境全体で一貫した構成と運用モデルを通じて、イノベーション、高性能で信頼性が高く安全な接続、分散アプリと API のゼロ トラスト セキュリティを実現できます。 このようにして、Environment-as-a-Service (EaaS) プラットフォームが実現され、applicationと環境の両方を一緒に実行し、バージョン管理できるようになります。 EaaS により、IT 部門はアプリや API をテストおよび実行するために最もコスト効率の高い環境を柔軟に選択できるようになります。

分散クラウド全体でアプリを接続、保護、展開する方法について詳しくご覧ください。

2) サイト共有サービス層

サイト レベルでは、グローバル ポリシーから逸脱するポリシーを指定できます。 これらのサイト全体のポリシーには、特定のロケールに適用される例外のみを含める必要があります。

サイト共有サービス層は、従来のアプリと最新のアプリの両方をサポートする上で重要な役割を果たし、レガシー システムと新しいクラウド ネイティブapplications間のギャップを埋めます。 同時に、この層は、サイトのセキュリティを確保し、システム全体の健全性を監視し、サイト内の個々のapplicationsの健全性を継続的に評価する上で重要な機能を果たします。 これらの機能を一元化することで、回復力、堅牢なセキュリティ対策、サイトでのアプリとシステムのメンテナンスに対する積極的なアプローチが促進されます。

BIG-IPapplicationサービスを使用して、アプリケーション トラフィックを拡張し、インフラストラクチャを保護する方法について説明します。

3) アプリサービス層

アプリ サービス層では、アプリ セグメントの保護をさらに強化します。 このレイヤーは、グローバルレベルおよびサイトレベルのポリシーを無視し、アプリ固有の保護ポリシーに重点を置くことができます。

組織が従来の仮想マシン (VM) からより俊敏な Kubernetes ベースの環境に移行するときに課題が生じ、最新の DevSecOps および CI/CD プラクティスを従来の VM および従来の API ゲートウェイとシームレスに統合することが困難になります。

最新のアプリの場合、 NGINX のような軽量で DevSecOps に適したマイクロゲートウェイと専用 API ゲートウェイが、コンテナ化されたサービス エンドポイントまたは従来の VM に導入されます。その主な機能は、エンタープライズ インフラストラクチャの特定のセグメントに特化したサポートを提供し、Kubernetes 環境におけるアプリのセグメント化のセキュリティを強化し、Kubernetes クラスター内の全体的なセキュリティを強化することです。

4) 管理および運用層

管理および運用層はマスター レベルを表し、自動配信、運用の可観測性、洞察に富んだ分析、シームレスに統合されたビジネス ワークフローを通じて、他のすべての層を統合する凝集力として機能します。

これは、インフラストラクチャをコードとして (IaC) アプローチとして採用し、アプリ ランドスケープのインフラストラクチャを自動化する層です。 このアプローチにより、事前定義されたセキュリティ ガードレールに準拠するアプリ アーキテクチャの管理と展開が簡素化され、統一された一連のプラクティスとツールを通じてチーム (NetOps、SecOps、DevOps) 間のコラボレーションが促進されます。 これにより、applicationsとそのサポート インフラストラクチャを大規模に迅速かつ確実に提供できるようになります。

アングが最終的に旅の終わりに到達し、4 つの要素をマスターし、世界の調和を維持するように、この 4 つの層を通じた構造化されたアプローチは、コンピューティング リソースの割り当てと管理に役立ち、最終的により調和のとれたアプリ アーキテクチャを実現します。

さまざまな層を採用することで、アーキテクチャは組織にさらなる柔軟性と適応性を提供し、ワークロード セグメントを展開する場所を決定し、総所有コストの削減と開発速度の向上を実現できます。

一元化されたアプリ/API 管理プラットフォームを通じて、すべてのワークロードとapplicationsを統一された視点で把握できるようになります。 これにより、リアルタイムのパフォーマンス監視も簡素化され、チームはパフォーマンスが低いクラスターを迅速に特定し、自動化されたプロセスとスクリプトを実行してパフォーマンスの問題に積極的に対処できるようになります。

適切に構造化された SaaS ベースのフレームワークは、スケーラビリティを容易にするだけでなく、必要に応じて追加のリソースを動的に割り当てることも可能にします。 たとえば、ユーザーのアクティビティが活発な期間にはより多くのコンピューティング能力を展開し、逆に需要が低い期間には不要なリソースを削除することでコスト効率を最適化できます。

最も重要なことは、これにより、NetOps や SecOps から DevOps やアーキテクトに至るまで、すべての役割がapplication内で必要なレベルのアクセスと権限を維持し、システム管理のためのセキュリティ、コンプライアンス、および役割ベースのアクセス管理が促進されることです。

誰もがAirbenderになれるわけではありませんが、これら 4 つの考慮事項が満たされれば、アプリ アーキテクチャの達人になることは間違いありません。