あすたぴのブログ

astap(あすたぴ)のブログ

AWSのIAMベストプラクティスをちゃんとやる(見る)

IAM のベストプラクティスをちゃんと理解しようというお話。

目的

このエントリでは、細かいやり方は書かない。 (ドキュメントを見ればいいし、コンソールを開けばわかる) こういうことをしたほうがいいんだよ。という内容を把握し、いざ、必要な時がきたときに知ってるいる状態にすることが目的

対象読者

  • AWSはEC2とかたてたりするけど、*1ルートアカウントでコンソールをいじってる人
  • EC2にIAMインスタンスプロファイルのロールを付けるとは??な人
  • 権限とか難しいから、フルアクセス付けてるよ?な人

IAMとは?

AWS Identity and Access Management (IAM) の略 アイアムって読んでます。(正しいかは知らない)

IAMを使うと、どんな事ができるのか

  • ルートアカウント以外にアカウントを作成できる。
    • 会社のAWSアカウントを複数人で触る際に、個人個人にアカウントを発行する。
    • 外部(CI等)から、AWSにアクセスする必要がある際に使うアカウントを発行する。
  • 作成したアカウントに対して、*2リソースごとにアクセスを制限できる

ルートアカウントを共有しない。 フルアクセス権限を全員に渡さない。 誰が何のリソースをどこまで操作できるか。を制限しよう。 というのがIAMを使う理由の認識です。

やること

AWS アカウント(ルート)のアクセスキーをロックする

ルートアカウントはすべての権限があるため、 ルートアカウントの権限を用いて、AWSコマンド等を使用すると、請求情報まで取得できる。 見られて困るものは、見れないようにしましょうね。という話し

  • アクセスキーを持ってるなら削除する
  • IAMで、管理権限を持つユーザーを作成する。
  • ルートアカウントのパスワードは強度の高いものを設定しよう。
  • ルートアカウントにMFAを設定する。

個々の IAM ユーザーを作成する

AWSにアクセスする必要がある場合は、IAMでユーザーを作成する。 IAMユーザーのアクセス許可は、いつでも、有効、無効にすることができる。 ※ルートアカウントは他人に絶対に教えてはいけない。 たとえ、個々のIAMユーザーに管理権限を付与するとしても、 ルートアカウントでない限りはアクセスを制限できるので、 必ず、IAMユーザーを都度、作る。

AWS 定義のポリシーを使用して可能な限り権限を割り当てる

ポリシーとは AWSではアクセス権限を制御するのにポリシーという定義を利用する。

ポリシー例

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": [
            "aws-portal:*Billing",
            "aws-portal:*Usage",
            "aws-portal:*PaymentMethods",
            "budgets:ViewBudget",
            "budgets:ModifyBudget"
        ],
        "Resource": "*"
    }]

}

AWS内でデフォルトで定義されているポリシーを使って可能な限り、権限を割り当てる。 メリットとしては、簡単。 デメリットとしては、権限の単位がざっくりしている。

例 - AdministratorAccess - フルアクセス権限 - AWSCloudTrailReadOnlyAccess - ClourTrailの読み取り権限

職務によって、ポリシーがAWSで定義されている。 職務機能の AWS 管理ポリシー

IAM ユーザーへのアクセス許可を割り当てるためにグループを使います。

ポリシーをIAMユーザー一人ひとりに付けるのは面倒だし、 複数人いても大体同じ権限になる。という場合に、グループを使う。

グループの作成

ここらへんで、単語が増えてきて混乱してきたと思うので、 以下にユーザ、ポリシー、グループの関係を整理。

  1. グループ作成
  2. グループにポリシーをアタッチ(付与】
  3. ユーザーをグループに追加

ポリシーはユーザーに直接アタッチも可能。

最小限の特権を認める。

まずは、最小限のアクセス(特定サービスへの権限、リードオンリー)を割当て、 必要になった際に権限を解放していくようにしよう。という話し

Access Advisorを使う アクセスアドバイザーは、コンソールでIAMユーザーを見る場合にタブの1つである。 該当ユーザーが、権限が付与されているサービスにいつアクセスしたかがわかる。 この項目を参照し、1度もアクセスをしていないサービスがあれば、 その権限はそのユーザーには不要な可能性があるため、 権限の見直しに使える。

ユーザーのために強度の高いパスワードポリシーを設定する。

IAM ユーザー用のアカウントパスワードポリシーの設定

IAMユーザーのパスワードに、パスワードポリシーを設定できる

特権ユーザーに対して、MFA を有効化する。

AWS での多要素認証 (MFA) の使用 ルートアカウント同様に、重要なリソースへの権限を持っているユーザーにはMFAを設定しようという話し。 例えば、(どのサービスでも)削除権限を持ってる人とか。

Amazon EC2 インスタンスで作動するアプリケーションに対し、ロールを使用する。

EC2上から別AWSサービスにアクセスすることはよくある。 そのアクセス権限は適切に定義しよう。という話し

ロールとは、AWSのリソースにアクセスできる権限の役割の定義

また新しい言葉が出てきたので、整理する。

  • IAM ポリシー
    • AWS上で扱う権限の一番小さい単位
  • IAM ユーザー
    • AWSにアクセスするユーザーの単位
    • グループに含めたり、ポリシーをアタッチして権限を付与する
  • IAM グループ
    • 複数のポリシーをまとめたもの
    • 複数のユーザーに同一の権限を与えるために使う
  • IAM ロール
    • 複数のポリシーをまとめたもの
    • ロールを付与したものに権限を委任することができる。
    • 主にはEC2インスタンスへ権限を付与する場合に使う
    • AWSアカウントのIAMユーザーにロールを付与することもできる。

認証情報を共有するのではなく、ロールを使って委託する。

さっきのロールの使い方での他AWSアカウントへは、アクセスキーを共有するんじゃなくて、 ロールを使おうね。という話し

認証情報を定期的にローテーションする。

定期的に認証情報を更新しようという話し

不要な認証情報の削除

使われていない認証情報があったら消そう。という話し

認証情報レポートや、awsコマンドで最後に使用した日付とかがわかるので、 それを見て、消す対象を精査できる。

追加セキュリティに対するポリシー条件を使用する。

ポリシーに対して、IPアドレスの制限が時間の制限を行うことができるので、 可能な限り、制限したほうがいいよ。という話し

AWS アカウントのアクティビティの監視

  • cloudfront
  • cloudtrail
  • cloudwatch
  • aws config
  • S3

の、アクセスログを利用して、不正なアクセス、利用と監視しようという話し

まとめ

全部やるのは過剰なのかな?という気もしますが、 そこは自分たちのやり方に合わせて、うまくやっていくのがいいのかなと思います。

*1:ルートアカウントとは、メールアドレス、パスワードでログインをするユーザーのこと

*2:AWSでは、ARNごとに、1リソースとして扱う。

がんばるための行動指針

本エントリは「行動指針 Advent Calendar 2016」の16日目の記事です。

キリがいいので、3つ書きます。

がんばらない

残業したり、がんばったり、根性論が嫌いなので、極力がんばらない為にどうするかをがんばります。 嫌いだと言いましたが、詳しく言うと、"出来ない"です。 体力がなさ過ぎて、がんばることが出来ないから、手段、ツール、知識、テクニックを用いて、がんばらないようにがんばります。 がんばれる人は本当にすごいと思います。おれはそれがしたくでも出来ないです。 当たり前ですが、あらゆる事を駆使して効率的に長時間がんばれたらそれが最強です。

これは、仕事に限らない話しです。 ゲームとかもそうですが、最近だと、効率を求めずにだらだらやる楽しみ。というのもわかってきました。 エンジョイ勢ってやつですね。

がんばらない2

努力ができることは才能だと思います。 周りがあの人は努力家だ。と思っていても、本人は努力だとは思っていないことが多いと思います。

自然にできること。がんばらなくてもできること。が自分に合ってることだと思います。 なので、今自分、がんばってるな。って思ったら、続けるか考えます。 がんばらない程度に続けるか、違うことに時間を使うか。 これもなんでもそうです。 仕事、人付き合い、ゲーム etc・・

物事の背景、理由、先にあることを考える。

これは仕事だけに限定しておきます。 我々エンジニアの仕事は、コードを書いて何かを作ること。だけではないです。 何のためにこの機能を実装するのか。を考えたり、 この機能を実装したあとで、何を期待しているのか。を考えたり、 そもそもこの機能はいるんだっけ。を考えたり、 技術的な観点で、この機能よりこっちのほうがいいかも。を考えたり、、、

全ての、仕事や行動などには理由があるべき、あるはずで、それをする理由がないならしないほうがいいかもしれません。 ここらへんは、状況に寄りすぎるので断定はしません。

また、これは自分が誰かに仕事を依頼する場合にも重要です。 背景、理由、あとの展望は成果物の質に大きく影響します。

まとめ

まとめると、全部自分を中心に考えています。 3つ目は物事の本質を捉えようとしている。とかかっこよくいえますが、 こういう考え方で仕事をしたほうが仕事量は減るからです。 自分を安定させてないと、他の(人の)事を考えられないので。

factory_girlの使い方を全体的にまとめた

factory_girlとは

factory_girlとは、 Rspec等の、Rubyのテストフレームワークで使用する、 テストデータ生成のためのライブラリ。

使い所

おもに、Activerecordのデータを生成することに長けている。 Activerecord以外のデータも生成可能だが、 生成ロジック等は自身で書くことになる。

併用ライブラリ

テストデータ生成といっても、データの中身は別途用意する必要がある。 そこで使われるのは、faker。 fakerの使い方は公式のReadmeを一部引用して軽く説明。

以下のような、記述で簡単に、ダミーデータを作成できる。

Faker::Name.name      #=> "Christophe Bartell"
Faker::Internet.email #=> "kirsten.greenholt@corkeryfisher.info"

fakerと組み合わせてfactorygirlを使っていく。

単一テーブルのデータ生成

テーブル

+-----------------+--------------+------+-----+---------+---------------------+
| Field           | Type         | Null | Key | Default | Extra               |
+-----------------+--------------+------+-----+---------+---------------------+
| user_id         | int(11)      | NO   | PRI | NULL    | auto_increment      |
| nickname        | varchar(100) | NO   |     | NULL    |                     |
| created_at      | datetime     | NO   |     | NULL    |                     |
| updated_at      | datetime     | NO   |     | NULL    |                     |
+-----------------+--------------+------+-----+---------+---------------------+

モデル

class User < ActiveRecord::Base
end

上記のような、usersテーブルがあったとする。 これを、factorygirlで生成する。

FactoryGirl.define do
  factory User do
    nickname { Faker::Name.name }
  end
end

上記がfactorygirlの定義

id, created_at, updated_at は activerecord側で生成されるので、 nicknameだけを指定すればよい。

user = create(:user)

生成時は上記のように書けばいい。

補助的なデータの生成

例えば、user生成時に指定したユーザーとフレンド関係になっていてほしいとか

Friendsテーブルがあるとする。

id
user_id
friend_id
created_at
updated_at
FactoryGirl.define do
  factory User do
    nickname { Faker::Name.name }
    
    factory :friend do
      transient do
        friend_id ''
      end
      
      after(:create) do |user, evaluator|
        Friend.new(user_id: user.id, friend_id: evaluator.friend_id)
      end
    end
  end
end
user = create(:user)
friend = create(:friend, friend_id: user.id)

factory定義中にfactoryを定義することができ、 これを行うとfactoryを継承することができる。

上記の場合は、Userを継承し:friendを作成している。

factoryの定義では、factoryの生成周りで、callbackが呼ばれる。

  • after(:build)
  • before(:create)
  • after(:create)
  • after(:stub)

stub以外は、activerecodのbuild,create前後のことだと考えてOK stubについては今回は扱わない。

transientは一時データを、初期から定義、外部から渡すことが可能。 今回は、friendになるユーザーのIDを外部から渡している。

最初からフレンドを持っているユーザーを生成する

ユーザー生成時に、フレンドもついでに作成したいケースもある。 factoryの定義に、traitを指定して、factory生成にパターンを持たせる事ができる。

FactoryGirl.define do
  factory User do
    nickname { Faker::Name.name }
    
    trait :with_friends do
      transient do
        friend_count 1
      end
      
      after(:create) do |user, evalutor|
        evalutor.friend_count.times.each do |_i|
          Friend.new(user_id: user.id, firned_id: create(:user).id)
        end
      end
    end
  end
end
user = create(:user, :with_friends, friend_count: 2)

これで、user生成時に、friendを指定数だけ一緒に生成する定義が出来る。 今回は追加データを生成するパターンに使っているが、 作成するデータのデータ内容のパターンに使うことも可能。

belongs_toが関係のデータ生成

Userモデルに従属しているテーブルがあったとします。

PostsテーブルとUserモデル、 Postモデル定義

id
user_id
created_at
updated_at
class User < ActiveRecord::Base
  has_many :posts
end
class Post < ActiveRecord::Base
  belongs_to :user
end

Postモデルのデータ生成時に、依存しているデータの生成も併せて行えます。

FactoryGirl.define do
  factory Post do
    user
  end
end
post = create(:post)

userモデルに従属しているということをPostファクトリ定義時に指定している。 これは、以下の記述と同様の意味になっている

FactoryGirl.define do
  factory Post do
    association :user, factory: :user
  end
end
user = create(:user)
poset = create(:post, user: user)

逆に、Userのデータはすでに生成済で、 そのUserに対してPostのデータを生成したい場合は上記のように、引数として渡すことができる。

従属している側から生成することはあんまりない気がするので、 たいていの場合は後者の記述。もしくは、friendのときのように、 :with_postsみたいにtraitでpost持ちのUserを生成する定義を書いたほうが使いやすい。

その他

別のテーブルの関係とかは、だいたい、after(:create)とか before(:create)とか、使えば、なんでも作れる。

traitでパターンを定義したが、複数パターンを組み合わせたい場合は、 別途定義ができる

factory :male_admin,   traits: [:male, :admin]   # login will be "admin-John Doe"
factory :female_admin, traits: [:admin, :female] # login will be "Jane Doe (F)"  

単一のtraitの場合は、factoryの引数に指定していたが、 複数を組み合わせる場合は別factoryとなる。

user = create(:male_admin)

まとめ

factorygirlの機能を組み合わせると、細かくパターンごとにテストデータの生成が可能になる。 うまく定義することで、テストコードのデータ作成部分がスッキリするのでおすすめ。

ここに書いたことは、全部公式にのっている

転職して1年がたったので振り返ります。

一応退職エントリ(のつもり)です。

だれですか

@astapi (あすたぴ)といいます。

IT系の受託開発の会社で新卒から9年働いていました。

顧客は割りと大きめの会社で、内容は言えないのですが結構面白い仕事もやらせてもらっていました。

2015年11月1日にSupership株式会社に入社し、1年が経ったのでこの1年でやったことを振り返ってみようと思います。

転職をしたいと思った理由

転職をしたいと思った理由としては3つあります。

1つ目が一番大きな理由ですが、エンジニアとして働きたかったです。

9年も働いていると自然と管理職になり、自然とコードが書く量が減っていきました。 そういう仕事ではなく、ちゃんと自分の手でコードを書きたかったです。

2つ目は開発の環境です。

受託開発である以上、顧客から開発環境(言語、サーバー)等を指定されることも多いです。 且つ、昔から続いている、保守案件も多かった為、アーキテクチャ的には古いものが多くありました。

3つ目は、自分がサービスを作ってる感がほしかったです。

受託開発のため、自分がこれを作っている。 このサービスをやっている。というのはなかなか言えません。 もっと、自分がこれを作っているんだ。いいものを作って世に出したい。 という思いを持って、開発がしたかったです。

転職してからやったこと - 勉強編

自分に実力が足りないことはわかっていたので必死に学びました。具体的には、

  • 基礎を学ぶ
  • スキルを深める
  • エンジニアとしての活動の幅を広げる

の3つです。

基礎を学ぶ

自分は専門学校卒できちんとしたコンピューター・サイエンスを学んでいません。 なので、コンピュータ、プログラミングの基礎、歴史からしっかり学ぼうと思ってこれらを読んでいました。

どんな技術でも、最終的にはコンピュータに命令を行うことになります。 その際に使用している、システムコールを意識することはたまにはあるかもしれません。 自分の使っている言語、ライブラリなどが最終的にコンピュータに対してどのような命令を行っているのか、明確に見なくてもイメージすることは、その技術を正しく使うにあたって重要だと思います。

歴史を知ることはいまの技術の理解につながります。 技術は、日々時代と共に、進歩を続けてきていますが、古い技術はもう使えないということはなく、 新しい技術でも古くからの伝統的な素晴らしい考えに沿っているものがほとんどです。 歴史を知ることはいまの技術の理解につながります。

読み終わっていないものも多いので、絶対にちゃんと読みますw

スキルを深める

現在、サーバーサイドエンジニアとして、APIを作っています。 サーバーサイドといっても、アプリのコードを書くだけではなく、 意味合い的にはフロント以外のすべてをやる。という意味です。 それに必要な技術を深掘りしようとしました。

インフラ

プロジェクトはオンプレではなく全AWSなので、AWSでも通じる知識、AWSではどうするのか。 itamae, packer, terraform, cosul等のインフラ構築ツールを学びました。 基盤こそ、インフラエンジニアの方が作ったものですが、いまは、私がサービスのインフラ改修も行っています。

インフラは全部コード化されていて、AWSのコンソールから直接構築することはありません。 AMIのイメージはpackerで構築しています。 とはいっても、AMIの作り直しは言語のversionが上がったり、した時くらいです。 AWS環境の構築はterraformで行われています。 AWS上のインスタンス間はconsulでクラスタ化されていて、 deploy時はconsulのリーダーからクラスタのメンバーへ通知を行ってます。

サーバーサイド

プロジェクトでElixirを使ってるので、ErlangとElixirをやりまくってました。 Elixirは、ErlangVM上で生成される軽量プロセスを大量に利用した、 並行、並列処理が得意で、非同期処理を頻繁に使いたいシステムと親和性が高いです。

Rubyは、プロジェクトで使っているのもあり、しっかりと学ぼうとしました。

新しい技術を学ぶときは、既存の技術には何か問題があり、 問題を解決するために新しい技術を作っている人がいる。 どんな問題をどう解決しようとしているのか? を考えると、その技術の使い所、使い方を見えやすくなるのでおすすめです。

エンジニアとしての幅を広げる

他、業務とは関係ないですが以下のようなこともやりました。 上司との1on1で、こういうことをやりたいんです。って言ったら、 じゃあやってみよう。って背中を押してもらったのでやりました。

オープンソースへの関与など

  • ライブラリを作った。
  • OSS開発
    • てきとうにgithubで探したライブラリにpull requestを送った。
    • 感謝されたけど、取り込まれはしなかった。
    • やり取りが暖かくて嬉しかった。(英語)

勉強会での登壇や運営への参加

Elixirの勉強会 tokyo.ex にて、LTと、パネルトークをしました。

Elixirを本番で導入しているという観点から、多少は話せたのかな・・・。

ご縁があり、運営としても参加させてもらっています。 (積極的に手伝えておらず、申し訳ないです。)

転職してからやったこと - 仕事編

非常に楽しく仕事ができました。

楽しく仕事ができる環境を用意してもらい、本当にありがとうございます。 一番良かったことは、任せてもらい、失敗をさせてもらえたことです。(勝手に失敗して勝手に直してる)

自分で設計して、自分で導入して、自分で失敗に気づいて、自分で改善策を調べて自分で直しました。

1つのサービスで、機能追加や改修のたびに、 (自分で書いた)良くない部分を直しつつ、進めてきました。 これが非常に、よかったです。

デザインパターンや、コードの設計に関することが非常に苦手で、 どこに適用すればいいのか、適用したらどうなるのかがいまいちイメージが出来ていませんでした。 自分が失敗したと、思ったことをパターンに当てはめて、 改善することで初めて、使えるようになったと思っています。

振り返り

プライベートの学習を振り返ってみると、 これだけしかやっていないのかと思いました。

自分的には、なんとなく1年前に比べたらかなり成長したなぁ。

という感覚があったのですが、 まとめてみると、あっさりしている気がします。

昔はアウトプットを意識していたのですが、 この1年はインプットの割合が多すぎました。 これからは、学んだことをしっかりと自分のためにも残していこうと思います。

終わりに

最近読んだ中で好きなマンガで、BlueGiant、ベイビーステップがあります。

この2つの本に共通しているのは、 最初から強い、何か特別な能力を持っているわけではない主人公が、 地道に地道に1つ1つを積み重ねて成長していく。というところです。

自分は、そんなに頭が良いわけでもなく、 理解が早いわけでもないので、 この本の主人公たちのように1つ1つを積み重ねていかないとダメだと思っています。

これからも、いまよりがんばって積み重ねていきたいと思っています。 ここまで読んでくれてありがとうございました!!!

おまけ

Supership株式会社ではエンジニアを募集しています。

興味がある方はSupership HP,wantedllyから応募するか、

私にお声がけください。