クラウドネイティブ権限を構築するための 5 つのベスト プラクティス

クラウドネイティブ/マイクロサービスベースの製品は複雑であり、これらの製品に対するアクセス制御の構築と権限の管理も複雑です。そして、プルリクエストをするたびに状況は悪化するばかりです。ほとんどの開発者は、製品に対して認証やアクセス制御を複数回構築することになり、新しい顧客、製品、またはセキュリティ要件ごとにリファクタリングを余儀なくされます。

人々の仕事や生活を楽にするためには、クラウド ネイティブの権限の構築に伴う特有の課題を理解し、開発者の悩みを大幅に軽減できるクラウド ネイティブの権限の構築に関する 5 つのベスト プラクティスを学ぶことが重要です。

アプリケーションとアクセス権限が変更されました

開発者はこれまで、認可やアクセス制御を備えた Django や Spring などのモノリシック フレームワークを使用して認可を構築してきましたが、クラウド ネイティブ アプリケーションを作成する場合、これらはもはや適切ではありません。

これにはいくつかの理由があります:

• まず、アプリケーション自体はもはやモノリシックではなく、マイクロサービスに基づいており、高度に分散化されています。これは、開発者がエッジに展開され、アクセス制御も必要になることが多いデバイスやインスタンスを統合する必要がある場合にも注目に値します。
• 2 番目に、クラウド ネイティブ アプリケーションでは、多くの場合、サードパーティのサービス (課金、認証、データベース、分析など) を統合する必要があり、開発者自身のアプリケーションのマイクロサービスに加えて、それらへのアクセスを制御できる必要があります。
• 3 番目に、より動的で分散化されたアプリケーションでは、複数のデータ ソースとますます複雑化するルールに基づいた、さまざまな承認モデル (RBAC、ReBAC、ABAC など) を使用する必要があります。最後に、セキュリティ、プライバシー、コンプライアンスの要件も（ますます高度化するサイバー脅威に直面して）高まり、非常に複雑になっています。開発者は、誰がデータにアクセスできるかだけでなく、そのデータがさまざまなサービス間でどのように移動するかも管理することになります。

エンパワーメントの現実

これらすべての新しい要求には、認可についての異なる考え方が必要です。

• 委任はもはや後から考えるものではなく、事前に計画する必要があります。
• 委任は一度限りの解決策ではなく、継続的な取り組みです。製品とともに進化し続けなければなりません。
• エンパワーメントは、ユーザー同士がつながり、他のユーザーを製品の使用に招待する方法に影響を与えるため、顧客体験の鍵となります。体験が良くなければ、彼らはそれを気に入らないでしょう。
• 承認は、より広範な ID およびアクセス管理スペースに接続します。

クラウドネイティブ権限を構築するための 5 つのベスト プラクティス

これらすべての変更に対処するために、開発者がクラウドネイティブの権限を構築し、権限の処理に圧倒されることなく実際に機能を開発する時間を確保するのに役立つベスト プラクティスがいくつかあります。

1. 戦略とコードを分離する

クラウド ネイティブの権限を構築するための最も重要なプラクティスの 1 つは、ポリシーとコードを分離することです。認証レイヤーのコードとアプリケーション コード自体を混在させると、非常に問題が発生する可能性があります。さらに重要なのは、コードがさまざまなマイクロサービス間で複製されると、アップグレード、機能の追加、コード全体の監視が困難になる状況が発生することです。変更のたびに大量のコードをリファクタリングする必要があり、マイクロサービスが進化するにつれて、コードは互いにさらに離れていくだけです。

これは、他のサービスが認証ニーズに使用する別の認証マイクロサービスを作成し、ポリシーをコードから分離することで（理想的には）回避できます。たとえば、Open Policy Management や Spice DB などのオープンソースのポリシー/権限エンジンを使用すると、開発者は別のサービスで認証を管理できます。

2. イベント駆動型

開発者は、構築しているアプリケーションが動的であることを期待しています。アプリケーションには、ユーザーの招待、ロールの割り当て、サードパーティのデータ ソースの使用などの機能が含まれることが多く、これらはすべてリアルタイムで管理する必要があります。この能力がなければ、権限委譲の決定を下す能力は大幅に低下します。

このため、開発者は認証レイヤーをイベント駆動型として設計する必要があります。彼らが目指しているのは、認可に影響するイベントが発生するたびに、それが直ちにシステムを通過して、認可レイヤーがそれを認識し、アプリケーションおよび関連するサードパーティのデータ サービスと同期が維持されるようにすることです。

理想的には、これを実現するには、開発者が認証データをアプリケーション データから分離し (アプリケーション関連のデータはすべて認証関連ではないため、またその逆も同様)、認証レイヤーに無駄のないモデルを作成し、リアルタイム イベントを介してアプリケーションやその他のソースと同期を維持します。

たとえば、Open Policy Management Layer は、オープン ポリシー管理をイベント駆動型にするオープン ソース プロジェクトです。これにより、開発者はポリシーやデータの変更に対応し、エージェントにリアルタイムの更新をプッシュし、リアルタイム アプリケーションに必要な速度でオープン ポリシーを有効にできるようになります。

3. ステークホルダーのバックエンド統合

承認レイヤーは製品自体の一部であり、製品中心の企業では、アクセス制御エクスペリエンスに接続できる必要があるさまざまな関係者が存在します。これらには、開発者に加えて、DevOps、製品マネージャー、セキュリティ、コンプライアンス、営業、マーケティングなどが含まれます。認証レイヤーを構築する際には、バックエンド システムを通じてさまざまな関係者にコントロールとインターフェースを提供したいと考えています。これには、アクセス制御インターフェースから製品に至るまで、さまざまな利害関係者のニーズを最初から考慮する必要があります。誰もが満足するはずです。

4. 顧客インターフェース

利害関係者の要件を考慮するのと同様に、開発者もエンドユーザー/顧客を考慮する必要があります。ライセンスは、製品の管理だけでなく、製品のエンドユーザーにも関係します。たとえば、ユーザーが自分の監査ログにアクセスする必要がある場合 (ほぼすべての B2B アプリケーション ユーザーがそうします)、製品で何が行われたかを簡単に確認できる必要があります。このニーズを事前に認識するには、エンドユーザーのニーズを満たすさまざまなインターフェースをロックダウンできる認証レイヤーを構築する必要があります。

5. GitOps

そのため、権限を管理するための別のマイクロサービスが作成され、イベント駆動型で更新を提供できるようになりました。では、これらの変更をどのように管理し、バージョンを適用し、さまざまなチェックとバランスを適用し、マイクロサービスのコードとデータがニーズと要件を満たしていることを確認するのでしょうか?答えは GitOps です。

GitOps を使用すると、開発者はバージョンの変更ごとにプル リクエストを作成できます。その後、開発者が製品とそのアクセス制御機能を更新するときに、新しいコードを含むコミットをプッシュし、必要なテストとチェックを実行して、認証レイヤーに適用できます。

クラウドネイティブ権限の未来

複雑さが増し、顧客要件とセキュリティ要件が次々と出現するにつれて、製品のアクセス制御を将来に対応し、大規模なリファクタリングや書き直しを必要としない方法で設計することが重要になります。認証用の個別のマイクロサービスを作成し、それをイベント駆動型として設計し、さまざまな利害関係者や顧客にコントロールとインターフェースを提供し、GitOps を使用することで、開発者は将来性を最大限に高めた製品を作成し、需要に関係なく認証レイヤーを複数回再構築する必要がなくなります。