トリの豚ですが、二日目が空いていると締まらないので本人の許可なく勝手に埋めさせてもらうこととする。
勢いで書いた文章のため、短文かつ内容は薄い。主張したいことは簡潔である。
はじめに
昨今のサーバレスアーキテクチャの趨勢に考えを及ぼすと、不特定多数のエンドユーザーがクラウド上のリソースに対して直接的にアクセスするアーキテクチャについても、視野に入れていかねばならなくなるであろう。
クラウド上のリソースとは、例えるならAWSにおけるS3やGoogle Cloud Storage、その他様々な情報を配信するマネージド・サービスを指すこととする。
そして、その際に前提として考えなければならないのは、そのエンドユーザーが真にそのリソースにアクセスする権限を有するかどうか、という点である。
AWSの場合
AWSはこの課題に対し、AWS STS(Security Token Service)という形で解決策を提示している。
STSを用いることで、ある特定のリソースに一時的に有効な、特定のアクションを実行する権限を、一時的な認証情報という形でエンドユーザーに払い出すことができる。
詳細な説明はAWSの公式ページに譲るとして、早い話が動的にIAM credentialsをリクエスト単位で生成できるようなものである。
一時的セキュリティ認証情報は、その名前が示す通り、使用期限が短くなっています。有効期限は数分から数時間に設定できます。認証情報が失効すると、AWS はそれらを認識しなくなります。また、その認証情報によって作成された API リクエストによるあらゆるタイプのアクセスが許可されなくなります。
一時的セキュリティ認証情報はユーザーとともに保存されることはなく、ユーザーのリクエストに応じて動的に生成され、提供されます。一時的セキュリティ認証情報が失効すると（または失効する前でも）、ユーザーは新しい認証情報をリクエストできます。ただし、リクエストするユーザーがまだその権限を持っている場合に限ります。
参考: http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_temp.html
GCPの場合
まだ解決策はない。なんとかしてほしい。
おわりに
かつての苦しみはどこへやら、クラウドを採用することで僅かな工数でサービスが出来上がる。といった未来はまだ訪れていないが、ビジネスにおける本質的な価値の追究に、エンジニアはそのリソースを集中させることができるようになってきた。
同時にクラウドサービスが勢いを増し、その選択肢が多岐にわたる中で、自らが所属する組織、ないしは状況に応じて適切な解を導き出すのもまた至難である。
本稿を例にとっても、一つの技術要素の有無によって、取るべき選択は変わってくる。エンジニアはエンジニアリングによって価値を追究すべきであり、独りよがりにそれを追究するのではなく、ビジネスの内容も踏まえて適切な判断が下せるよう、努力していきましょう。