こんにちは、普段ほとんど家で冷房を使わないので、時々都会に行くと建物の中が寒すぎてびっくりするセキュリティエンジニアリングの西川です。
先日Security-JAWS DAYS（https://s-jaws.doorkeeper.jp/events/155024）に登壇させていただきました。30回記念という節目に登壇できたことがただただありがたかったです。運営のみなさま本当にありがとうございました。
今日は登壇資料をふまえつつ、時間の関係で話せなかったことなどについて書いていきたいと思います。
おさらいも踏まえてご覧ください。
Amazon Verified Permissionsとは
Amazon Verified Permissions（以降、AVP）というのはアプリケーション開発の認可を請け負うサービスで、ソースコードから認可判断部分を切り出し、AVPに移譲することが可能です。 認可を切り出すことによって、アプリケーション側でそれを意識することがなくなるというのが最大のメリットで、開発効率が上がります。 認可というのは、誰に何をさせるか/させないかをポリシーに応じて決定します。 これを外部に移譲することによって、ソースコードを変更せずに柔軟に認可ポリシーを変更できるようになります。
登壇資料にも書いているとおり、現状、AVPではRBAC(Roll Based Access Control)とABAC(Attribute Based Access Control)の二つの権限モデルに対応しています。あらかじめリソースの関係性を有向グラフで記述し、グラフの関係性に基づき認可判断を行うReBAC(Relationship-Based Access Control)があると良いなと個人的には思っていて、 今後使えるようにはなると思うのですが、一方で、ReBACが対応している認可サービスでもシュッとそれを導入できるかというとそうでもないらしいので、そこはあまり重要ではないのかもしれません。
Cedarについて
AVPではポリシー言語としてAWSがオープンソースとして公開しているポリシー記述言語のCedar(https://www.cedarpolicy.com/en)を採用しています。なのでAVPを使わずともCedarの評価サーバを立てることにより、ローカルでも認可の仕組みを作ることは可能です。一方で、認可のサービスが落ちてしまうとサービスそのものの提供が難しくなってしまいます。認証と違い認可は常に問い合わせを受ける必要があり、速いレスポンスとともに高い可用性を維持する必要があり、マネージドサービスを使うというのは賢い選択肢だといえます。その分お金は掛かりますけれども。
認可サービスは難しい
正直認可サービスは難しいです。re:Inforceのセッションでは開発効率が20%上がったという話がありましたが、開発効率が上がったとしても、運用コストが上がっては元も子もありません。では、運用コストが上がらないようにするためにはどうしたらよいかというと、サービスの設計、それからAPIの設計を認可サービスに合わせて行うということだと思っています。登壇の際にも触れましたがでも話をしましたが、ビジネスロジックに認可の条件が入ってしまうと、条件を多重管理することになったり、脆弱性が生まれてしまう可能性があります。アプリケーションコードには認可の条件を一切いれずに、何かあったらAPIの本数を増やすという強い意志が必要です。 APIのベストプラクティスやドメインモデルそのものと、認可を外部に移譲する場合のベストプラクティスというのが一致しているのかちょっとわからないのですが、認可を外部に移譲する際のベストプラクティスがあれば、より一層AVPなどのサービスを利用しやすくなるのかなと個人的には思っています。
認可サービスと相性が良いサービス
このブログでお伝えしたいことはこれです。
AVPというよりは認可自体の話ではありますが、いくつか相性がよいサービスがあると思っています。一つ目は、IoTなどの機器の制御です。例えば、re:Inforceではデルタ航空の話がありました。インターネットに繋がっているかや、速度や高度の状況などに応じて、乗客がエンターテインメントサービスにアクセスできる/できないを制御するなどしていました。 また、認可のSaaSを使っている企業などを見るとテスラがあります。これはあくまでも想像ですが、例えば車が止まっている、動いているに応じてカーナビが操作できるとか特定のAPIを叩ける/叩けないを制御しているなどが考えられます。 また、懸念としてインターネットが繋がっていないときというのはあるかと思いますが、その場合はローカルに立てたポリシー評価サーバにアクセスしに行くみたいなことをすれば、可用性はある程度担保できると思っています。ただし、ポリシーの同期などの仕組みを考えておく必要があります。
あとは、プロキシサーバーを構築して、その中にAVPを組み込むとSaaSごとにアクセス制限がかけられたり、機密性の高いリソースに対してアクセス制限が掛けられたりするのではないかと考えていたりします。いわゆるCASBみたいな使い方です。 最近はプログラミング言語によってはプロキシーサーバーを簡単に構築できるものもあるのでシュッとできたりするかもしれません。
そんなことを考えていたらGoogleは、Tool Proxyというものを作成していることを知りました。いわゆるZero Touch Production（ZTP）を実現するもので、これは簡単にいうと人間がプロダクション環境を直接触ることができなくするというものです。人間が直接アクセスできなくすればセキュリティの向上が見込まれる一方、利便性が悪くなる可能性があります。どうしても本番環境でコマンドを実行したい！という状況が訪れた場合に「どうしたらいいの？」となってしまっては本末転倒です。しかもそれがサービスの運用に関わることであればなおさらです。 ですので、そのときにこのTool Proxyを介してコマンドを実行できるようにしておきます。コマンド実行者に許可されているコマンドかどうかや、コマンド実行者がコマンド実行を許可されているグループに所属しているかなどをポリシーで判断します。またここで実行されたコマンドや実行者は監査ログに出力されるので、あとからその妥当性を確認することができるようになり、事前にその実行するコマンドが承認を受けているかどうかというのを確認する仕組みも実装することができます。 個人的にはこういう使い方をすることによって認可サービスが監査とセットで語られることが多いというのが腑に落ちました。
今現在私の中でWebサービスに認可を組み込むのは割と難しい印象を持っていますが、こういう組織内部で使って知見をためて、Webサービスに組み込んでいくのがよいのではないかと思っています。
おわりに
当日の発表はトップバッターということで結構な重圧でしたが、結果的に終わったあと予想以上に多くの方から質問をいただくことができて、自分の登壇内容はともかくとして場の流れを作るという点に関してはよかったのではないかなと思ったりします。AVPがGAされてから「AVPすごいよ！」と手放しで賞賛する声が各方面で聞こえてきていたのですが、個人的には大変なことも多いのでは？という想いがあり、利用前にそういうことも知っていただく機会になればと思っていました。
今回、この登壇のCfPを書いた時から構想はあったものの、他のサービスとの違いなどは社内の認証や認可に詳しいメンバーに認可そのもののこともふまえていろいろ教えてもらって、自分自身多くのことを勉強することができました。 まさに登壇駆動と言えることもたくさんあり、、、必要に駆られてやってみるというのは悪くないので、ぜひ皆さんも登壇駆動にチャレンジしてみてください！きっと困った時は誰かが手を差し伸べてくれるはずです！ どんどんアウトプットしていきましょう！
あらためまして運営の方々には貴重な機会をいただけたこと心より感謝申し上げます。
