Azureのストレージサービスでの権限管理

ストレージサービスと権限管理

AWS・Google Cloud・Azureといったクラウドサービスを使っている中で、何をするにしても 使う頻度が非常に高い ものといえば、 ストレージサービス ですよね。

サーバレスな環境からのデータ保存といった用途もあれば、ウェブサイトホスティングのオリジンとして使ってみたり、まさに 縁の下の力持ち 、という感じがします。

今の私なら断言できます。好きなサービスはS3、GCSだと。 ニッチなサービスを指定すればオシャレに見えるとしても尚、縁の下の力持ちこそ評価されるべきだと思います。

そんな便利でかつパワフルなストレージサービスですが、一番重要な要素は何か、と問われると私は 権限管理 だと思います。

ストレージに保存するデータは当然意図せぬ形で漏洩してはなりませんので、可用性やらコストやらより先ず第一に権限管理だと私は認識しています。(ちょっと大げさですが)

ただ、今まで個人的にはあまりAzureでのユースケースがそこまで多くなく、先ほども好きなサービスはS3、GCSと言っていたように、Azure Blob StorageをはじめとするAzureのストレージサービスについてはまだまだ詳しくありませんでした。

最近、Azure Blob Storageで組織外とデータをやりとりすることがあり、そのときに権限管理について調べたので、その内容を整理していきます。本記事ではその中でも「SAS」と呼ばれるものによる権限管理についてまとめます。

SASとは何か

早速本題ですが、SASとは Shared Access Signatures (共有アクセス署名) の略称です。どうやらストレージへのアクセス制御に使えるようです。

というわけで、早速SASの公式ドキュメントを紐解いていくことになるわけですが、なかなかに紐解きにくいです。(個人の感想です)

なので、理解を進めた内容について纏め直していきます。

ストレージアカウントのアクセスキー

SASの話をする前に、まず、ストレージアカウントのアクセスキーの話です。

そもそもストレージアカウントというのは何かというと、AzureのストレージというのはAzure Blob Storage、Azure Queue Storage、Azure Table Storage、Azure Filesといったように複数のサービスがあるんですね。それを束ねているのがストレージアカウントです。

ストレージアカウントのアクセスキーというのは、ストレージアカウントの「セキュリティとネットワーク」の中の「アクセス キー」の項目内にあるものですね。

こちら、 フルアクセス権限 があります。公式ドキュメントにもその記載があります。

ストレージ アカウント アクセス キーは、ストレージ アカウントの構成とデータへのフル アクセスを提供します。アクセス キーは常に慎重に保護してください。キーを安全に管理およびローテーションするには、Azure Key Vault を使用します。 共有キーへのアクセスにより、ストレージ アカウントの構成とそのデータへのフル アクセス権がユーザーに付与されます。

と、ドキュメント全体の文字数が多すぎてやや伝わりにくいですが強めに注意を促しています。

つまり、 ここの接続文字列をそのまま外部に渡す、なんてことをしてしまうととたんに漏洩リスクが上がる わけですね。

だから外部に渡すならSASを使う

ストレージサービスへのアクセス権限を外部に渡すということ、これが公式ドキュメントでは 「委任」 と表現されていますが、これを安全に実施するために使うのがSASです。

SASのトークンを外部に渡すことで、フルアクセス権限のアクセスキーではなく、権限管理されたトークンを渡せるわけですね。

Azure Storage用に準備するSASは3種類

ドキュメントにある通り、SASには。

• ユーザー委任SAS

• サービスSAS

• アカウントSAS

の3種類があります。

ユーザー委任SAS は、Azure ADの資格情報を使うということで最も侵害されにくい方法とされています。Microsoft自体も推奨しているものです。アカウント自体のロールベースアクセス制御(RBAC: Role Based Access Control)と、SASにおいて付与する許可でアクセスをコントロールする方式ですね。個人的にもかなりナチュラルだと感じますが、トークン構築手順はやや複雑です。

次に挙げられているのが サービスSAS です。これと次のアカウントSASの差がAzureに慣れていないと分かりづらいのですが、要するに、「ストレージアカウント」というものの中にある、Azure Blob Storage、Azure Queue Storage、Azure Table Storage、Azure Filesというサービス単位で作成されるSAS、と理解しています。

そして最後の アカウントSAS ですが、こちらはストレージアカウント全体に対してのSASです。先ほどのサービス単位を複数指定できるものになっています。今回はこのアカウントSASの作成手順を紹介しようと思います。

アカウントSASの作成

実際にアカウントSASの作成画面を見てみましょう。

WEB画面からは、先ほどの「アクセスキー」の下にある「Shared Access Signature」で生成できます。

「SASと接続文字列を生成する」のボタンが画像では非アクティブですが、これは「使用できるリソースの種類」を指定することで有効化されます。

せっかくなので、いくつかの重要な項目について触れてみます。

有効期限の日時指定

こちらは設定必須です。渡すトークンがいつまで有効か、ということですが、広くとることもできますし、狭くとることもできます。

使用できるIPアドレス

IPアドレスでの制限をかけるとより確実になるので、可能な限り制限を付与したいですね。

署名キーの選択

ここでの署名キーは、先ほどの「アクセスキー」に対応します。

ということは、 アクセスキーをローテーションするとこちらのトークンも更新が必要になる ことには注意が必要です。

実際、そのような注意がinfoボタンから出てきます。

以上を踏まえて生成ボタンを押すと…

このように、接続文字列およびSASトークン、各種サービスのSAS URLが確認出来るというわけです。これでアカウントSASの作成は完了です。

まとめ

本記事ではAzureのストレージアカウントにおける権限管理に用いるSASについてまとめていきました。

やはり このあたりはクラウドベンダごとに差が出てくるところなので理解するのに学習コストがかかります が、かなり重要なところなので必ず抑えておきたいですね。どなたかの理解の一助となっていれば幸いです。

余談ですが、朝日放送グループホールディングスでは、まだマルチクラウドなどという言葉がそれほどポピュラーじゃなかった頃から安定性向上のためにAWS・Google Cloud・Azureを併用するようにしています。

いつの間にかクラウド二刀流なんて言葉も登場していますが、三刀流も目指していきたいですよね。強そうですし。それぞれの強みを正しく把握して使いこなせる人間になりたいですね。