エムオーテックス株式会社が運営するテックブログです。

採用情報

「署名付きURL」で何が守れるか考えてみた

AWS セキュリティ

「署名付きURL」で何が守れるか考えてみた

はじめに

こんにちは！ 品質管理部の立古です。

品質管理部に所属しながら、サービスの重要な品質特性のひとつであるセキュリティを維持向上するため、MOTEX PSIRT としても活動しております。

MOTEX PSIRTではエンジニアが日頃の開発やサービス運用においてぶつかる設計課題、特にセキュリティ面の課題に関して、相談対応やレビューを実施しています。 この活動を通してサービスの品質向上を図り、利用者へ安心安全なサービスをお届けできればと考えております。

今回は、そんな中で遭遇した一つの相談案件について紹介したいと思います。 この記事を通して、サービス品質・セキュリティ向上に対する、我々の取組み模様を感じていただけますと幸いです。

さて、ある日、開発者から 署名付きURL の採用可否について相談があったところから、今回の検討が始まりました。

背景となる要件

サービスの機能開発を進めるうえで、

「許可した人間/装置のみにデータへアクセスさせたい」

といった要件をしばしば見聞きします。

当社の開発現場に限らず、プログラムの開発に携わられるかたでしたら、日常的によく遭遇するのではないでしょうか。

では、この要件をどういった技術を使って実現すればよいでしょうか？

  • IDとパスワードを配布してログインしてもらう

というのは非常にベタな手段ですが、近年では新たな仕組みとして、

  • 署名付きURL

という選択肢を見聞きするようになりました。

データへアクセスしたい対象者のみに教える専用のURLを発行することで、パスワードなどを共有せずともURLへアクセスするだけでデータを提供することができます。 例えば、我々が基盤として活用する Amazon Web Services(AWS)においても、Amazon CloudFront や Amazon Simple Storage Service (S3) にて 署名付きURL 機能がサポートされています。

docs.aws.amazon.com

docs.aws.amazon.com

では、この 署名付きURL という機能を、どのような場合に採用するとよいでしょうか？

  • リスクプロファイル
  • 署名付きURLの仕組みとリスクとの対応関係
  • 他の対策案

の順で検討していきたいと思います。

リスクプロファイル

まずはじめに、改めて実現したい要件を整理しましょう。

「許可した人間/装置のみにデータへアクセスさせたい」

冒頭でご説明した通り、要件としてはシンプルです。

では、その要件を満たせないケース(=リスク)とは、いったい何でしょうか。

要件をひっくり返してみます。

「許可していない人間/装置がデータにアクセスしてしまう」

そんなことが起こるケースはあるのでしょうか。

例えば、以下のような要因が考えられます。

(※あくまで検討例であり、これで過不足ないことを保証するものではありません)

  • でたらめに操作したらアクセスできた
  • アクセス方法が漏えいした
  • 許可を取り消したのにまだアクセスできた
  • 実装上の問題

次の章で、それぞれの要因をもう少し具体化してみます。

でたらめに操作したらアクセスできた

前提情報を持たない第三者が、でたらめに突破できてしまうパターンを考えてみます。

1. 規則性がすぐわかった

例えば、「/data/download」 のようなベタなURLを打ってみたら、たまたま正解でダウンロードできた。 もしくは、パスワードを適当に 「1234」 など打ってみたらログイン成功した。

以上のような事態が考えられます。

2. 高性能PCで強行突破できた

例えば、「4桁の暗証番号を入力しないとダウンロードできない」ような制御を行ったとします。 4桁の暗証番号には1万パターン存在するわけで、確かに人間の力で正解にたどり着くには苦労するかもしれません。 ただ、人間の力を用いずとも、スクリプトを使って機械的にアクセスすることは可能で、それなら1万回程度のアクセスは一瞬で可能でしょう。

アクセス方法が漏えいした

次に、でたらめにアクセスせずとも、正解のアクセス方法がばれてしまっているパターンを考えてみます。

3. 管理方法が適切でなかった

例えば、たまたま第三者がオフィスを訪問した際、パスワードなどがディスプレイに付箋で貼ってあったので、横目で見て暗記できてしまったというケースです。 あまり考えたくないですが、実際問題として、ITに不慣れな環境では生じえるのではないでしょうか。

4. システム上の保護仕様が適切でなかった

例えば、パスワードを暗号化せず生のままでデータベース保管していたので、何かのきっかけでデータベースを閲覧できた者にばれてしまったというケースです。 表向きの見た目に現れない部分ですので、うっかり設定を間違える場合も考えられるでしょう。

許可を取り消したのにまだアクセスできた

一時的に許可していたものを、あとから無効化できていなかったパターンも考えられます。

5. 漏えいした権限を無効化できなかった

認証情報の漏えいが既に判明しており、対処しようとしたものの、 例えば有効期限を1年に設定していたために、漏えいしてしまった権限を無効化するのに1年待たないといけない、といったケースです。

再ログインの手間を軽減するためなど、便宜のため行っていた運用が仇となってしまうこともありますね。

6. 共用アカウントを使っていた

例えば、担当部署内の全員でひとつのアカウントを使っているようなケースが考えられます。 このとき、ある社員が部署を異動するため、アクセス権を無効化したいのですが、 アカウントを共用しているほかのメンバーは引き続きアクセスが必要ですので、アクセス権の取り消しができなくなります。

アカウントの取り扱いルールがうまく整備ができていないと、このような問題も生じうるのではないでしょうか。

実装上の問題

運用上の考慮がなされていたとしても、システム側の仕様により問題が発生することも考えられます。

7. 仕様理解を誤った結果として意図しない設定を行った

例えば、Aの権限を付与すると自動的にBの権限も付与するという仕様があり、その結果、意図せずBのアクセス権を付与してしまう、ということもあるのではないでしょうか。 権限設定は得てして複雑なので、他にも多種多様な誤解が考えられます。

8. システム側に問題があった

例えば、実装ミスにより、意図しない権限が自動的に付与されてしまうことも考えられます。

このような洗い出しを行ったうえで、どのリスクに対処したいか、ニーズに合う策を選びたいところです。

署名付きURLの仕組み

では、署名付きURLの仕組みを見ることで、上記ニーズとの対応関係を探っていきましょう。

例えば、AWSにおける署名付きURLの構成要素については、公式ドキュメントから確認することができます。 https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_sigv-authentication-methods.html

https://s3.amazonaws.com/amzn-s3-demo-bucket/test.txt ?
X-Amz-Algorithm=AWS4-HMAC-SHA256 &
X-Amz-Credential=<your-access-key-id>/20130721/<region>/s3/aws4_request &
X-Amz-Date=20130721T201207Z &
X-Amz-Expires=86400 &
X-Amz-SignedHeaders=host &X-Amz-Signature=<signature-value>

ポイントを順に見ていきます。

アクセス権限の付与

署名付きURLには AWS Identity and Access Management(AWS IAM) から発行されたアクセスキーが含まれており、 アクセスキーに与えられた権限でのアクセス制御が実施できます。

https://s3.amazonaws.com/amzn-s3-demo-bucket/test.txt ?

X-Amz-Credential=<your-access-key-id>/20130721/<region>/s3/aws4_request &

ちなみに AWS Security Token Service(AWS STS)が発行した一時アクセストークンからもURL発行が可能です。 その場合は X-Amz-Security-Token にトークンが付与されます。

なお、具体的にどんな権限のアクセスキーを含めるかは、URLを発行するシステムでの設定次第です。

有効期限の付与

署名付きURLには、発行日時と有効期限が付与されます。 そのため、有効期限を短く設定すれば、漏えいしたURLが無期限に利用されてしまうリスクを軽減できます。

https://s3.amazonaws.com/amzn-s3-demo-bucket/test.txt ?


X-Amz-Date=20130721T201207Z &
X-Amz-Expires=86400 &

なお、有効期限はURLを発行するシステムの設定次第で、最大値は7日です。 https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/using-presigned-url.html#PresignedUrl-Expiration

また、有効期限より遡って失効させるような機能を、署名付きURL側で持っているわけではありません。 (※遡って無効化したいとき、URLに付与しているアクセスキーを無効化すると、結果的にURLも無効となります。)

署名による偽造防止

署名付きURLには、内容の偽造を防止するためのデジタル署名が含まれています。 そのため、URLをでたらめに作成したり、URLを加工して権限や有効期限を細工したりできないよう考えられています。

https://s3.amazonaws.com/amzn-s3-demo-bucket/test.txt ?
X-Amz-Algorithm=AWS4-HMAC-SHA256 &

X-Amz-SignedHeaders=host &X-Amz-Signature=<signature-value>

署名付きURLはどんな課題に対処できる？

仕組みを踏まえて、署名付きURLはどの要件に対処できるでしょうか。

でたらめなアクセスに「対処できる」

  • 署名を第三者が生成することが困難なので、勝手なURLを指定したりすることは困難。
  • URLはじゅうぶんに複雑かつ署名で守られており、しらみつぶしにアクセスして突破することは困難。

以上の観点から、署名付きURLを使えば、この課題へ効果的に対処できそうですね。

アクセス方法の漏えいに「限定的に対処できる」

  • その都度こまめに生成して使い捨てる使い方をしている限り、盗み見て使うのは難しい。
  • 暗号化せず生で保管していれば漏えいしてしまう。

署名付きURLを使ってさえいればよい、というわけではありません。 ですが、署名付きURLを使えば運用上の取り扱いが簡単になるかもしれません。

許可の取り消しに「原理的には対処できない」

  • 有効期限内は(署名付きURL自身の機能としては)アクセス取り消しできない。
    • (※ URL作成元となる認証情報それ自体を無効化すれば、結果的にURLも無効化できます)
  • URL自体は、知ってしまえば誰でも共用で使えるから、一部メンバーに限定して権限付与したりはできない。

署名付きURL自体では対処できないので、周辺の機能や運用を別途考えなければいけません。

実装上のバグに「対処できない」

  • 署名付きURLに、設定ミスを救ってくれるセーフティネットのような機能は無い。
  • 署名付きURLは、与えられた権限をその通り使うだけで、権限設計そのものの問題には対処できない。

署名付きURLの利用有無とは別の部分で、対処を考えなければいけませんね。

他の対策案

署名付きURLでは対処できない要件について、どんな追加対策が取れるか、ごく簡単にまとめてみます。

漏えいに対処したい

  • URLの取り扱いルールを整備する
    • 開発者側でなく利用者側が取る対処です。例えばメールやチャットへの貼り付けを禁止するなど、URLを知れるメンバー自体を制限するような、運用上の工夫を行います。
  • 署名付きURLでアクセス可能な範囲を十分に絞り込む。
    • 万が一漏えいした時のダメージを軽減するアプローチです。

許可の取り消しを行いたい

  • アクセスキーの無効化機能を組み込む。
    • URLを無効化したいとき、対応するアクセスキーをすぐ無効化できるように、運用を考えておくか、自動で処理できる仕組みを実装します。
    • URLごとにアクセスキーを使い分けるなど工夫も必要です。複数のURLで同じアクセスキーを使うと、無効化時にすべて巻き添えになってしまいます。

実装上の問題に対処したい

  • 要件通りの権限となっているか検証する。
    • テストでの担保あるのみです。
  • 署名付きURLに使うアクセスキーを、他に使い回さない。
    • うっかり不要な権限を付与しないための工夫です。

このような観点を踏まえて、開発チームには十分な仕様を検討してもらいます。

おわりに

今回は「署名付きURL」をテーマに、セキュリティリスクの観点から設計考慮点などについて検討してみました。 当社の開発現場では、このように設計検討しながら、ユーザーへ安心安全なサービスを提供できるよう努めています。 ご参考になれば幸いです。