[memo]AWSへの入門以前に知りたいIAMまわり
[memo]AWSへの入門以前に知りたいIAMまわり:
たったいまAWSで苦しんでいる自分から、明日の自分と機能の自分へのメモです。
内容に間違いがあればぜひ教えてください。。。！
AWSはたくさんのサービスがあり、
特にインフラに不慣れな僕なんかはどこから触ったらよいのか、
むしろどこに触ったらいけないのかもわからず、色々困っています。
世の中にはありがたいことに「AWS 入門」あたりでググると、
それなりの数のページが出てきてくれますが、
「こういう事をやりたいんだけど」という目的が先にあったりすると、
関連性がわからないものも含めた全体の入門記事はちょっと重いもの。
とりあえずそういうせっかちな自分に向けて、
絶 対 に 押さえておきたい知識について。
AWSにおけるセキュリティは、大きく分けて三つに分類できます。
一つ目は秘密鍵などを利用した、暗号化によるセキュリティ。
こちらは今回は扱いません。
二つ目は「操作の権限」によるセキュリティ。
誰が何をできるのかを、AWSはかなり細かく制限できるようにしています。
具体的にいうとメソッド単位くらいまでです。
この部分を軽視していると「動くはずのサンプルが動かない」になります。
三つめは「アクセスの権限」によるセキュリティ。
誰が何にアクセスできるのかを制限します。
こちらは分かりやすいですが、個人でちょっと開発しようというくらいなら、問題になるタイミングはそう多くありません。
というわけで、操作の権限と、アクセスの権限についてさらっと紹介していきます。
AWSでは何をするにもIAM関連は避けて通れません。
「Identyty（自己証明）」という言葉の通り、
どのサービスを使うとしても、このIAMの設定に従うことになります。
IAMはそれぞれの権限について、以下のような構造で管理します
以下のようなコンセプトのために、
単語があてはめられたと言ったほうがよいかもしれません。
こちらはあまり詳しく説明しませんが、
AWSの中に、もう一つ自分専用のAWSを作れるようなサービスです。
VPCを使うことで、わりと簡単に、そこそこ強固なセキュリティを確保できます。
ただ、一部のサービス（S3など）はこの中に置くことができないため、
窓口としてエンドポイントを用意し、それを経由してアクセスするなどの段取りが必要になります。
ということで、自分が整理するためのメモとしてここにアウトプットを残しておきました。
あと個人的に先に知りたかったなーと思うこととして、
いま自分が触っているlambdaまわりについて、
わりと挙動がセンシティブなので、まずは以下の公式リファレンスをもとに、
そのサンプルをコピペしただけのラムダを作って、
それをもとに作っていくのをおすすめします。
AWSやAzureがデファクトになっている状況なので、
ググれば大体なんとかなりそうな気もしていたのですが、
フロントエンドの開発のつもりでいるとかなり痛い目を見ます。
AWSはあくまでインフラをラッピングしているだけなので、
問題の原因が「権限」なのか「アクセス」なのか「ソースコード」なのかなど、
切り分けが必要な部分が普通の開発よりも多い＋根深いため、
わりとググってもアテにできる回答は少ないのが、いまのところの雑感です。
https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/_index.html
上記記事で間違っている点などは指摘いただけると助かります。
あと、一人で悩んでもよくわかんないなーというときは、僕のTwitterに相談くれても大丈夫です。一緒に悩むくらいしかできませんが（笑）
また遠からず、できる範囲で入門記事を書いていきたいと思います。
AWSのサービス
誰向け？
たったいまAWSで苦しんでいる自分から、明日の自分と機能の自分へのメモです。内容に間違いがあればぜひ教えてください。。。！
はじめに
AWSはたくさんのサービスがあり、特にインフラに不慣れな僕なんかはどこから触ったらよいのか、
むしろどこに触ったらいけないのかもわからず、色々困っています。
世の中にはありがたいことに「AWS 入門」あたりでググると、
それなりの数のページが出てきてくれますが、
「こういう事をやりたいんだけど」という目的が先にあったりすると、
関連性がわからないものも含めた全体の入門記事はちょっと重いもの。
とりあえずそういうせっかちな自分に向けて、
絶 対 に 押さえておきたい知識について。
三種類のセキュリティ
AWSにおけるセキュリティは、大きく分けて三つに分類できます。一つ目は秘密鍵などを利用した、暗号化によるセキュリティ。
こちらは今回は扱いません。
二つ目は「操作の権限」によるセキュリティ。
誰が何をできるのかを、AWSはかなり細かく制限できるようにしています。
具体的にいうとメソッド単位くらいまでです。
この部分を軽視していると「動くはずのサンプルが動かない」になります。
三つめは「アクセスの権限」によるセキュリティ。
誰が何にアクセスできるのかを制限します。
こちらは分かりやすいですが、個人でちょっと開発しようというくらいなら、問題になるタイミングはそう多くありません。
というわけで、操作の権限と、アクセスの権限についてさらっと紹介していきます。
IAM (Security, Identity, & Compliance)
AWSでは何をするにもIAM関連は避けて通れません。
「Identyty（自己証明）」という言葉の通り、
どのサービスを使うとしても、このIAMの設定に従うことになります。
IAMはそれぞれの権限について、以下のような構造で管理します
- アカウント = 特権、全部できる、AWSのアカウントのこと、ユーザーとは別
- ポリシー = 各種の権限
- ロール = 権限をまとめて表現された役割
- グループ = ポリシーとロールをまとめたもの
- ユーザー = 操作の実行者
以下のようなコンセプトのために、
単語があてはめられたと言ったほうがよいかもしれません。
- 権限を細分化したもの => ポリシー
- 役割がもつべき権限の塊 => ロール
- 開発チームなどの単位で持つべき権限の塊 => グループ
- 作業者ごとの権限 => ユーザー
VPC (Virtual Private Cloud) & ACL (Access control list)
こちらはあまり詳しく説明しませんが、
AWSの中に、もう一つ自分専用のAWSを作れるようなサービスです。
VPCを使うことで、わりと簡単に、そこそこ強固なセキュリティを確保できます。
ただ、一部のサービス（S3など）はこの中に置くことができないため、
窓口としてエンドポイントを用意し、それを経由してアクセスするなどの段取りが必要になります。
ということで、自分が整理するためのメモとしてここにアウトプットを残しておきました。
あと個人的に先に知りたかったなーと思うこととして、
いま自分が触っているlambdaまわりについて、
わりと挙動がセンシティブなので、まずは以下の公式リファレンスをもとに、
そのサンプルをコピペしただけのラムダを作って、
それをもとに作っていくのをおすすめします。
AWSやAzureがデファクトになっている状況なので、
ググれば大体なんとかなりそうな気もしていたのですが、
フロントエンドの開発のつもりでいるとかなり痛い目を見ます。
AWSはあくまでインフラをラッピングしているだけなので、
問題の原因が「権限」なのか「アクセス」なのか「ソースコード」なのかなど、
切り分けが必要な部分が普通の開発よりも多い＋根深いため、
わりとググってもアテにできる回答は少ないのが、いまのところの雑感です。
https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/_index.html
終わりに
上記記事で間違っている点などは指摘いただけると助かります。あと、一人で悩んでもよくわかんないなーというときは、僕のTwitterに相談くれても大丈夫です。一緒に悩むくらいしかできませんが（笑）
また遠からず、できる範囲で入門記事を書いていきたいと思います。
コメント
コメントを投稿