クラウドアプリケーションの最新アクセス制御を構築するための5つのベストプラクティス
2022年11月15日
0 分で読めます先日、Or Weis氏（Snyk Ambassador）と、クラウドにおけるアクセス制御について話し合いました。テルアビブを拠点とする起業家のOr氏は、Permit.ioを設立しました。同社のソリューションを使えば、開発者はあらゆる製品に数分で権限とアクセス制御を組み込めるため、何度も再構築する手間を省けます。
対談では、次のようなさまざまなトピックを取り上げました。
クラウドで常に最新のアクセス制御を使うことが重要な理由
RBACだけでは不十分な理由
セキュリティとコンプライアンス
クラウドにおけるアクセス制御のさまざまなレイヤー
IAMのウォーターフォール
アクセス制御の構築時に攻撃対象領域を縮小する方法
さらに、クラウドアプリケーションにすぐに取り入れられるアクセス制御のベストプラクティスについても話し合いました。このブログ記事では、対談の内容をもとに、それらのプラクティスを振り返ります。詳しく知りたい方は、対談の全編をご覧ください。
最新のクラウドアクセス制御に関する5つのベストプラクティス
アクセス制御を自分で構築する場合も、オープンソースや独自ツールを使う場合も、構築するシステムを将来にわたって使える堅牢なものにし、安定性と保護を支えるガードレールを設けるために、次の5つのベストプラクティスを実践しましょう。
コードとポリシーを分離する
イベント駆動型の更新を前提に設計する（データとコードを分離する）
ステークホルダー向けの管理画面を設計する
顧客向けインターフェースを作成する
GitOpsを導入する
1. コードとポリシーを分離する
最初の、そしておそらく最も重要なベストプラクティスは、ポリシーとコードを分離することです。認可ロジックをアプリケーション自体のロジックに組み込んでいるケースをよく見かけます。最終的には、認可ロジックを取得するためにデータベースやほかのソースを照会しつつ、アプリケーションロジックも並行して処理する「if」条件が入り乱れた、スパゲッティコードになってしまいます。時間が経つにつれ、それらはたいてい絡み合っていきます。開発者が新しい条件を追加するにつれて、「if」条件のどの部分が認可のためで、どの部分がアプリケーションのためなのかを把握するのはほぼ不可能になります。
その結果、認可レイヤーやアプリケーション自体をアップグレードする際には、コードを一行ずつ確認してリファクタリングする必要が生じ、つらい作業につながります。そこで、ポリシーをコードから切り離すことが重要です。ポリシー・アズ・コード（PaC）を採用し、コードを個別に管理しましょう。理想的には、独立したマイクロサービスとして管理し、アプリケーション内のほかのコンポーネントが必要なロジックを取得できるようにします。
この分野に初めて取り組む開発者からは、次のような疑問が出てくるでしょう。
そのサービスへのアクセスを制御するのは誰か？
認証とアプリケーションのどちらが先か？
率直に言えば、これは「認可のための認可」と呼ばれる、非常に複雑で再帰的な領域です。簡単に言うと、後続レイヤーのアクセス制御を最小限に抑え、多くの場合は認証だけに絞ることができます。つまり、マイクロサービスが認可用マイクロサービスに接続する際は、そのマイクロサービスが確認できるIDを持っていれば接続を許可できます。レイヤーを重ねると複雑さは増しますが、多くのツールがその問題を解決するか、少なくとも負担を大幅に軽減してくれます。
認可用の独立したマイクロサービスを作るのが理想だということを覚えておきましょう。そのマイクロサービスは、最初から完璧である必要はありません。初期段階では、常に「true」を返すだけの単純な関数でもかまいません。最初からすべてを構築する必要はありませんが、新しい要件が出てきたときに段階的に改善できるよう、プレースホルダーを適切につないでおきましょう。Lambda関数でも、小さなコンテナでも、どのような形でもかまいません。追加要件に応じて、独立して進化させ、容易にリファクタリングできるものである必要があります。
2. イベント駆動型の更新を前提に設計する（データとコードを分離する）
2つ目のベストプラクティスは、イベント駆動型にすることです。複雑なシステムではポリシーも複雑になり、アプリケーションの規模や構成に応じて変化します。最初からイベント駆動型に設計しておけば、将来の更新を管理しやすくなります。
例を見てみましょう。次のようなシンプルなポリシーを考えてください。機能の料金を支払ったユーザーだけが、その機能を利用できる。この情報は、もはや自社のデータベースやアプリケーション内にはありません。Stripe、Chargebee、PayPalなどのサードパーティサービスにあります。そこで、こうしたサービスの情報変更をリアルタイムで伝播させ、認可レイヤーに反映できるようにする必要があります。
そのための最善の方法が、イベント駆動型にすることです。つまり、外部サービスやコンポーネントからWebhookを受け取り、認可レイヤーに伝播できるようにします。これは「データとコードの分離」と呼ばれ、ポリシーとコードを分離するのと同じくらい重要です。
3. ステークホルダー向け管理画面 + 4. 顧客向けインターフェース
顧客や、プロダクトマネージャー、セキュリティ企業などのステークホルダーがいる以上、アクセス制御を管理するためのインターフェースが必要になります。最初から構築する必要はありませんが、要件が出てきたときに作成して提供できるよう、準備しておきましょう。
さまざまなステークホルダーがアプリケーションを管理できる管理画面を用意し、顧客自身がユーザーを招待したり、ロールを割り当てたり、ポリシーを設定したりできるインターフェースも提供したいところです。多くのエンジニアが同意するように、最良のサービスはセルフサービスです。
5. GitOpsを導入する
最後に、ポリシー・アズ・コードに話を戻すと、GitOpsでセキュリティをシンプルにできます。複雑なルールや指示を、常に変化し、多くのステークホルダーが関わる環境で管理することを考えてみてください。管理する最善の方法は、コードを使うことです。Infrastructure as CodeやSecurity as Codeと同様に、Policy as Codeも取り入れるべきです。
ポリシーを独立したコード（理想的には、その用途に適したフレームワーク内）としてGitリポジトリで管理すれば、バージョン、テスト、ベンチマーク、コードレビューを効率的に管理できます。こうすることで、ポリシーの管理方法やシステムとの接続方法を一から考え直す必要がなくなります。
常に最新の状態を保つ
何かを構築し始めるときは、この5つのベストプラクティスを念頭に置いてください。いずれ必要になることをあらかじめ意識しておくだけで、後のリファクタリングに何か月も費やさずに済みます。
最後に、このテーマについて話を聞かせてくださり、専門知識を共有してくださったOr Weis氏に心から感謝します。このテーマについて質問がある方は、TwitterまたはLinkedInでOr Weis氏に連絡するか、DevSecCon community Discordに参加して直接質問してください。
CTFを始めよう
オンデマンドのバーチャル入門ワークショップで、CTFチャレンジの解き方を学びましょう。