こんにちは、せーのです。今日はセキュリティ上確認しておく必要があるrootアカウントの情報についての新項目追加のお話です。 rootのアクセスキーは作らないほうが良い セキュリティを考える上で普段の運用に対して費用も含めた全ての権限が付いているrootアカウントを使うべきではありません。そこで普段はIAMユーザーを作成し、権限に応じてIAM Groupを作り、ユーザーをそこに所属させて運用させます。 つまり普段使わないrootアカウントに対してアクセスキーの発行はもちろんするべきではなく、もし発行していたらそれは削除しておいた方が安全です。セキュリティ認証情報も同じですね。万が一それが漏れる事を考えると管理リスクがありますので、そもそも作らない、というのがセキュリティ的には正解です。セキュリティ保全の観点から言うとrootに限らず「要らない認証情報は速攻削除」が基本方針です。 rootのキ

【新機能】IAMユーザーをManagement Consoleからクロスアカウントで色々なRoleにスイッチする事ができるようになりました。 こんにちは、せーのです。今日はIAMにできたなかなか面白い機能をご紹介します。IAMで役割(Role)を予め作っておき、AWS Management ConsoleからIAMユーザーをそのRoleにスイッチさせることにより一つのユーザーで様々な役割でのアクセスが可能になる、というものです。 どういう時に使うの 普段IAMユーザーに役割を割り振る時にはその業務別で権限を分けているかと思います。例えばDeveloper(開発者)であれば開発環境には触れるけれども本番環境には触れない、運用担当であれば状態を見ることはできるけども変更することは出来ない、みたいな感じです。 でも一時的に権限を与えたい場合などがあるかと思います。本番環境にシステムをデプロイする

こんにちは、せーのです。明日から仕事、という方も多いのではないでしょうか。徐々に頭を通常モードに切り替えていきましょう。 さて、今日ご紹介するのはごくごく個人的な備忘録です。あと最近クラメソに入社した、という方もちらほら出てきているのでその方々向けの情報提供でもあります。AWSのリリース情報やアップデート情報のチェック方法についてまとめてみました。 ただ情報はどうしても英語になってしまいます。ですので日本語で詳しく知りたいんだ、という方はここ、developers.ioをチェックしてください。全記事読んでいる、という強者の方は是非右上からエントリーを。 何語でもいいからとにかく1秒でも早く最新情報が知りたい、という方はこれから書くURLをチェックしておくと、大体の最新情報が手に入るかと思います。 基本はリリースノート ここは外せません。サービスのアップデート情報等はここに載るのでまずここを

ども、大瀧です。 本日、AWSより2015年3月にIAMポリシードキュメントの文法チェックが厳格化するというアナウンスがありました。具体的にどんな対策をするべきか、まとめてみました。 確認方法 まずは、対策が必要かどうかを確認します。IAMのDashboard画面(https://console.aws.amazon.com/iam/)にアクセスして、画面上部に「Fix Policy Syntax」の警告が表示されたら対策が必要、表示されなければ対策は不要です。 警告が表示されたら、早速警告文末尾にある[Fix Syntax]リンクをクリックしてPolicy Validatorを表示します。 Policy Validatorによるポリシードキュメントの修正 Policy Validatorのリストには、修正が必要なポリシー一覧が表示されます。ポリシー名をクリックすると、自動修正前と修正後の

Enable 2FA for your favorite sites. Go beyond the password and protect yourself from hackers and account takeovers. Download our free app and follow our guides:

アプリのインストール 電話番号とEmailを登録 電話番号とEmailを登録します。 認証 続いて認証 今回はSMSを選択しました。 登録した電話番号宛にpinコードが送られるので認証します。 プラスボタンを押して次へ進みます。 バックアップ設定 Authyは2段階認証のデータを暗号化してコピーしておいてくれるので携帯電話をなくしたり、壊したりしてもバックアップパスワードさえ覚えておけば復元がきるようですのでバックアップパスワードの設定をします。 バックアップパスワードを入力します。 再度入力します。 Scan QR Code あとはGoogle Authenticatorなどと同じようにQRコードを読み込んで使用します。 QRコードを読み込むとアカウントネームの編集やロゴの選択ができます。 ロゴはこんなにたくさん用意されています。 今回はAWSのロゴを選択してみました。 MFAコードが表

こんにちは、虎塚です。 先日のCM re:Growth Developers.IO Meetup 11 Tokyo で「10分でわかるKey Management Serviceの仕組み」という発表をしました。今日は、イベントに参加されなかった方がご覧になっても内容が伝わるように、発表内容を記事に起こしてみました。 はじめに Key Management Service（KMS）は、先月開催されたre:Invent 2014で発表された新サービスです。すでに全リージョンで利用できます。このサービスを使うと、データの暗号化/復号用の鍵をAWS上で管理できます。 ところで、KMSのAPIドキュメントを流し読みすると、マスターキーとデータキーという言葉が出てきます。そうです、KMSが扱う鍵は2種類あるんですね。 2つの鍵の違いは何か？ どう使い分けるのか？ などが、ぱっと見ではわかりづらいかもし

はじめに タイトル通り、Cloud Trailでサポートしているサービスを一覧に纏めてみました。参考にしたのはSupported Services(以下、元記事とします)です。 Cloud Trail サポートサービス一覧 では、一覧です。元記事にはサービス毎にCloud Trailの使用方法へのリンクが付いているのですが、一部は直接的な使用方法となっていない箇所もあります。そのようなリンクへは「※」を、また私が追加リンクについては「★」をつけてあります。 サービス種別 サービス名 使用方法

この記事は AWS re:Invent 2014、SEC305-JT - IAM Best Practices - Japanese Trackのレポートです。 スピーカーはAWSのAnders Samuelsson。 レポート IAMとは？ 機能でもありサービスである。誰が何をできるのかを制御する。 ユーザ、グループ、ロール、パーミッションのコントロール。 全てのサービスへのアクセスを一箇所で一元的に制御できる。 粒度が細かく、どこまでなにをするのかはみなさんが決められる。 Denyがdefault。許可を与えない限りは出来ない。 複数のユーザを作ることも、透過的に設定することもできる。 ベストプラクティスは10個あったんだけど、11個になりました。 一番最初にやること。Userを作る。CLIでもAPIでもAMCでも。 ユーザを作ったら何ができるか。権限がないので何も出来ない。 まずは権

こんにちは、虎塚です。 今回のre:Inventで発表されたAWS Key Management Serviceは、データを暗号化するためのキーをAWS内で生成、削除、ローテートなどの管理ができるサービスです。このサービスは、キーを管理するユーザと、キーを利用するユーザを別々に定義できるのが特徴です（同じにすることもできます）。 この記事では、まず、キーの管理と利用の違いを説明します。次に、アカウントをまたいでキーを利用し、S3にアップロードするオブジェクトを暗号化する例を紹介します。 AWS Key Management Serviceのキーを別アカウントで使用することは、まさに管理と利用の分離の一例です。アカウントをまたいで、二つの役割を定義するわけですね。 キーの管理と利用 キーの管理と利用について理解するには、自分で作成したキーのポリシーを見るのが分かりやすいでしょう。大瀧さんの記

ども、大瀧です。 開催中のAWSプライベートイベント、re:Inventで続々と新サービスが発表になっています(他のブログエントリーでチェックしましょう)！今回は、AWS Configという新サービスに触ってみたのでレポートします。 AWS Configとは AWS Configは、その名前の通りAWSが提供する様々なサービスのコンポーネントの構成情報を管理するサービスです。従来からAWSには変更管理や操作証跡を取得するAWS CloudTrailというサービスがありますが、こちらはAWS APIのコールログを取得する仕組みであり、どの状態からどの状態に変更されたのかといった状態に関する情報をまとめて管理するには不向きなサービスでした。AWS Configを利用すると、AWSリソースのいわゆる履歴管理、構成管理が実現できます。 今回のリリースでは、バージニア(us-east-1)リージョン

本日のre:Invent Keynoteにて、新サービス「AWS Config」が発表されました！現在はNorth Virginiaリージョンのみで利用可能な限定プレビュー版となっています。 AWS Configとは？ AWSのインフラ上にはEC2やRDSといった様々なリソースが構築されます。最初は単一のEC2から開発が始まり、RDSが追加され、セキュリティグループに新たなエントリが加わり...というように、AWSの構成はどんどん複雑なものになっていきます。その構成を管理・変更の検知などを行ってくれるのがAWS Configの機能です。 11/12現在、AWS Configは以下のリソースをサポートしています。画像は公式ページからのキャプチャになります。 主な機能として以下が挙げられています AWSリソース間の依存関係の記録(例: EC2インスタンスとセキュリティグループなど) 設定変更の

CloudTrailの中身を直ぐに確認したい CloudTrailは、AWSのAPI操作に対する監査機能です。AWSの各種サービスは全てAPIを使って利用します。このAPI利用履歴について全て保管し、監査をすることで、誰がいつ何処から何をしたのか確認することができます。エンタープライズ用途では待ち望まれた機能ですが、ひとつ難点がありました。ログの管理や閲覧の機能を持っていないことです。今回の新機能追加によって、CloudTrailに保管されたタイミングでSNSの通知が飛び、CloudWatch Logsに保管することで、ログの文字列に対する、フィルターやアラームを設定できるようになりました。日時バッチなどでチェックするのではなく、ログが発生したタイミングで確認ができるのが特徴です。今回ははじめからやってみましょう。 S3にログ用のバケットを作成 S3のメニューから新規にバケットを作成します

ウィスキー、シガー、パイプをこよなく愛する大栗です。 皆さんはAWSをセキュアに利用する為に、MFA(多要素認証)を使ってManagement Consoleへログインしていますよね？ でも管理者以外の一般IAMユーザを使用している方はMFAを使用していないのではないかと思います。MFAの登録にはIAMの権限が必要になるので、一般ユーザでは登録できない事がほとんどだと思います。IAM権限の設定は面倒なので、必要な権限を整理してみました。 必要な権限 以下の様なIAMポリシーを設定したグループを作成しましょう。なお"ACCOUNT-ID-WITHOUT-HYPHENS"は自分のAWSアカウントの値に置き換えて下さい。 下記ポリシーは、2015年8月時点で試したところ、上手く動かなかったようです。対応についてはIAMユーザ本人にMFAを管理してもらうためのIAMポリシーを御覧ください。 { "

よく訓練されたアップル信者、都元です。AWS APIへのアクセスログ機能を提供するCloudTrail、皆様ご利用でしょうか。正直よく分からなければ、何も考えずにこのスクリプトを流して設定しておくことをお勧めします。 そういえば先日、フランクフルトリージョンがオープンしましたね。フランクフルトのCloudTrail有効化はお済みでしょうか？ *1 まだであれば今すぐ設定しましょう！ CloudTrailログの活用 前述の通り、CloudTrailのログ出力は、とりあえず何も考えずに有効化しておくことがお勧めです。万一、セキュリティ事故を疑うような場面に遭遇しても、頑張ってログを解析することにより、いつ、だれが、何をしたのか、が克明に記録されており、追跡が可能になります。 しかしこのようなCloudTrailの活用法では、事故が発生したとしても、気づかなければ何もできません。言わば消極的な活

よく訓練されたアップル信者、都元です。突然ですがMFA使ってますか。使ってますよね。使ってますよね！ 今どき大事なAWSアカウントをパスワードでしか保護しないのが許されるのは小（自粛 さて、本エントリーですが、下記の流れの追補的な位置づけになります。 IAMによるAWS権限管理運用ベストプラクティス (1) IAMによるAWS権限管理運用ベストプラクティス (2) なので前提知識として上記を読んでおいて頂きたいのですが、忙しい方には下記引用を。 まず、AWSにおけるクレデンシャルは大きく2種類に分かれます。 Sign-In Credential：Management Consoleログインのためのクレデンシャル（要するにパスワード） Access Credentials：APIアクセスのためのクレデンシャル（要するにAPIキー） MFAは、主にManagement Consoleへのログイ

三井田です。 昨晩は『JAWS-UG CLI専門支部 #3 - IAM入門』に参加してきました。 JAWS-UG CLI専門支部については、甲木さんが「JAWS-UG CLI専門支部に参加しています #jawsug」で既に触れているので割愛します。 JAWS-UG CLI専門支部 #3 IAM入門 今回は４回目の勉強会ということで「#3 IAM入門」がお題でした。（#0から始まったので#3は４回目なのです） 『JAWS-UG CLI専門支部 #3 - IAM入門』にリンクのあるハンズオン資料を基にもくもくと時に雑談や相談を交えて進んでいきました。 特にIAMのハンズオンという観点で主宰の波田野さんから提起された注意点としては、次のようなものがありました。 AWSアカウントはまっさらな新規アカウントを用意した方が良い。誤操作により、同じアカウントを使っている同僚その他が突然環境を使えなくなる

渡辺です。 最近は、システムの開発支援としてAWS環境構築などに関わる事が多いです。 そこで、開発者側視点で押さえておきたいAWSのノウハウや基礎知識を書いて展開してみたいと思います。 今回はEC2で動くプログラムがアクセスキー/シークレットキーを使わずにRoleを利用すべき、という話です。 Roleとは？ RoleはIAMの機能のひとつで、アクセスキー/シークレットキーを使わずに各種AWSリソースにアクセスすることができます。 例えば、EC2インスタンスからS3にオブジェクトを書き込んだり、SNSにメッセージを送信したりする場合に利用できます。 アクセスキー/シークレットキーとの違い ひとことで言えば、Roleはアクセスキー/シークレットキーに比べ、キーの管理をする必要がありません。 ただし、EC2インスタンスにしか割り当てることしかできません。 キー管理が不要 アクセスキー/シークレッ

よく訓練されたアップル信者、都元です。EC2の世界にはキーペアという登録エンティティがあります。EC2サーバにSSH接続するための鍵 *1としての働きを持ちます。 暗号技術のおさらい 突然ですが、暗号の世界の技術を大きく3つとりあげ、簡単に整理しておきましょう。私の説明は正確ではないと思いますので、あわせてWikipediaあたりの説明もご参考に。 暗号：情報のヒミツを守る。詳しくは → 暗号 - Wikipedia 電子署名：ある文章を、ある人が認めた状態から改ざんされていないことを確認する。詳しくは → 電子署名 - Wikipedia 認証：通信の相手が、想定した本人であること（正当性）を確認する。詳しくは → 認証 - Wikipedia 一般的に暗号というと思い浮かべるものは「共通鍵暗号方式」でしょう。代表的なところでは暗号化zipでしょうか。暗号化時と復号化時に同じパスワードを

こんにちは。望月です。 先日(といっても結構前ですが)、ついに待望のCloudTrailの全リージョン対応が発表されました。 その前からそうだったかは未調査ですが、CloudTrailを有効にしていない場合に、AWSのTrusted Advisorで警告が出るようになりました。 この警告を消すためにも、全リージョンでCloudTrailを有効にしましょう！ スクリプト化してみた ですが、手作業でぽちぽちやるのはアレなので、自動化しました。既にj3tm0t0さんがAWS - 全リージョンのCloudTrailロギングを有効にするワンライナー - Qiitaにてワンライナーを公開されていますので、そちらを使うのもいいと思います。このワンライナーではS3バケットと適切なBucket Policyが設定されていることが大前提なので、まだBucketを作成していないアカウントでは、先にS3バケットを

よく訓練されたアップル信者、都元です。CloudTrailは、AWS APIの全ての呼び出しについて、それを行った主体（principal≒ユーザ）やIPアドレス、リクエストやレスポンスの詳細を記録し、そのログをS3に出力してくれるサービスです。このサービスがあることにより、不正アクセスがあった場合の追跡が可能になります。また「記録されているから悪事は働けない」という心理的な予防効果も期待できます。 CloudTrail自体を狙われる危険性 しかし、この証跡ログはS3のバケットにファイルとして配信されるため、悪意のあるユーザによる証拠の隠滅の可能性を考慮しなければなりません。 まず、全リージョンでCloudTrailを有効にした後は、CloudTrail自体の停止を禁止する必要があります。そんなポリシーステートメントはこちら。CloudTrailへの状態変更を行うアクションについては明示的

はじめに AWS CloudTrailのアップデートが発表されました。 Release: AWS CloudTrail on 2014-07-24 : Release Notes : Amazon Web Services 今回のUpdateは「Support for sign-in events」です。 CloudTrail now records attempts to sign into the AWS Management Console, the AWS Discussion Forums, and the AWS Support Center. All IAM user sign-in attempts (successes and failures), all federated user sign-in events (successes and failures), an

はじめに こんにちは植木和樹です。先日IAMについて機能拡張のアナウンスがありました。早速、大瀧さんがブログに書いていますね。 強化されたAWS IAMパスワード管理を理解する ｜ Developers.IO このブログ読んででふと気づいたのですが、"Allow users to change their own password"のチェックボックスは以前からありましたでしょうか？ 画面に表示されているヒントには "Enables all IAM users to change their own passwords. You can allow only specific users to change their own passwords by clearing this box and allowing this action in their IAM user or group

こんにちは、せーのです。 今回はIAMの権限管理について便利な方法をCDP候補「assumeGroup」パターンとして提案させて頂こうと思います。 どういう時に使うのか 例えばEC2のSTOP/START/REBOOTだけの権限を与えたいユーザーがいるとします。これを「operator権限」とします。 通常はIAMユーザーに直接EC2へのpolicyを書いて解決しますね。 でもそれですと他にoperator権限を付けたいユーザーがいた場合、毎回そのpolicyを書き続けないといけません。めんどいですね。 そこでIAM Groupを使ってそれを解決します。つまり、operator権限をもったIAM Group(operatorグループ)を作り、そこに権限をつけたいユーザーを所属させることで皆operator権限を持つ、という方法です。これでIAMユーザーと権限管理が分離しました。 しかしEC

ども、大瀧です。 本日IAMの新機能としてパスワード管理の機能追加とクレデンシャルレポートの出力がリリースされました。IAMユーザーの管理をよりセキュアにする良い機能拡張だと思うので、アップデート内容をまとめてみます。 パスワード管理の機能追加 従来からIAMユーザーのパスワード設定として、最小文字数などが設定できたのですが、今回の機能拡張で設定項目が大幅に増えました！一般的なパスワード管理で必要とされる項目は一通り網羅されているのではないかと思います。設定画面は従来通り、Management ConsoleのIAMのメニューにある[Password Policy]で確認、設定出来ます。 設定名 はたらき

はじめに こんばんは、武川です。先日弊社ブログにAWSアクセスキー・ローテーションのススメという記事がありました。こちらは手動にてコンソールを操作する手順となっていますが、折角なのでスクリプトで実行できるようにしてみました。 スクリプトとそのの実行方法について簡単に説明します。 スクリプトについて rubyで書いてみました。 #!/usr/bin/env ruby require 'rubygems' require 'aws-sdk' AWS.config({ :access_key_id => 'Please input Your Access Key', :secret_access_key => 'Please input Your secret Key', :region => 'ap-northeast-1', }) iam = AWS::IAM.new() if iam.ac

よく訓練されたアップル信者、都元です。ブログのエントリみてればわかるとおもいますが、最近AWSのセキュリティに凝ってます。 AWSにおける権限管理について知識を深め、各所に適切な設定を行って行くのは大事なことです。これが基本です。しかし、自分が管理するAWSの各種リソースについて、何らかの意図しない変更があったことにすぐ気付ける体制は整っていますでしょうか？ 仮に、アクセスキーが悪意のある第三者に漏洩し、当人がその事実に気づいていないケースを考えます。悪意の第三者は、きたる攻撃のタイミングに備え、各所にバックドアを仕込もうとするでしょう。 こっそりとIAMユーザを増やしているかもしれません。 アクセスキーが1ユーザにつき2つ作れることをいいことに、自分用のキーを追加で作成しているかもしれません。 IAMロールに対するIAMポリシーを書き換えているかもしれません。 セキュリティグループにおけ

よく訓練されたアップル信者、都元です。以前IAMによるAWS権限管理 – IAMポリシーの記述と評価論理というエントリにて、IAMポリシーの書き方を解説しました。 先のエントリで、ポリシーステートメントはEffect, Action, Resourceから成る、という説明をしました。これはこれで基本的に間違い無いのですが、Actionの代わりにNotAction、Resourceの代わりにNotResourceというキーが利用できる、ということを本日はご紹介しようと思います。 Allow-NotActionとDeny-Actionの違い ステートメントにおけるNot〜を理解するにあたって理解しなければならないのはこのテーマに尽きます。下記2つのポリシーはどう違うのでしょうか。 Allow-NotActionパターン { "Version":"2012-10-17", "Statement"

よく訓練されたアップル信者、都元です。現状、AWSの管理コンソールには、どのIPアドレスからでもログイン可能です。しかし、管理コンソールへのアクセスを社内ネットワークからのみに絞りたい、というニーズは常に一定数存在します。という時に使えるTipsを今回は軽くご紹介。 IAMポリシーによる制御 残念ながら、現状ではIPアドレス条件で「管理コンソールへのログインを出来なくする」ことはできません。しかし、IAMポリシーの記述を工夫することにより「管理コンソールへログイン出来たとしても、情報の閲覧をはじめ、各種操作が一切できない」状況にすることができます。 例えば、Administratorアクセス権限を与えるが、指定IPアドレス以外からのアクセスを全て却下する場合は、下記のようなポリシーを適用します。下記の例では、203.0.113.123/32以外からのアクセスは拒否されます。 { "Vers

はじめに こんにちは。望月です。 過去に本ブログで、IAM Roleの仕組みについて都元から解説がありました。 - IAMロール徹底理解 〜 AssumeRoleの正体 IAM Roleの仕組みについて非常にわかりやすく解説されていますので、ぜひ読んでみてください。今日はもう少し利用側の観点に立ったブログを書いてみようと思います。 IAM Roleってどうやって使われてるの IAM Roleを利用する目的は、「ソースコード内にAWSのAPIキーをハードコードすることなく、AWSのAPIを叩きたい」というものが殆どだと思います。ですが、なぜIAM Roleを利用すると、アクセスキーをソースコードで指定することなくAWSのAPIが利用可能になるのでしょうか。 今日はその仕組みについて知りたくなったので、AWS SDK for Rubyのソースコードから読み解いてみました。SDKのバージョンは1

よく訓練されたアップル信者、都元です。さっきはヤられました…。早速ボスに「同じネタの記事書いちゃったんですよーｗｗ」という話をしたら、想像通りのドヤ顔を頂きました。ごちそうさまでした。 さて、マジで悔しいので再びMFAネタ。 MFAを滅失した場合 前のエントリで説明した通り、アカウントのセキュリティ向上にはMFAが有効です。特にルートアカウント（非IAMアカウント）はアカウントの解約までできてしまう、最も強い権限を持っていますので、是非ともMFAを活用したいところです。 しかし、MFAというのは基本的に個人に帰属してしまいがちなデバイスです。業務で利用するAWSアカウントについて、そのルートアカウントにMFAを設定した場合、そのMFAを持ち歩くのは、恐らくそのプロジェクトの責任者ということになります。 では、その責任者がMFAと共に、何らかの事故に巻き込まれてしまった場合、どうなるでしょう

こんにちは、せーのです。 今日はとても悲しいことが起きたので、ブログを書きたいと思います。 事の顛末 今朝のことです。 東京は小雨が降っておりまして、傘を指しながら徒歩で会社まで通勤しておりました。 信号待ちで何気なくスマホを取り出したところ、雨で滑ってしまい、道路に落としてしまいました。 よくあること、、、なんですが、今日に限ってどこの打ちどころが悪かったのか ...こうなってしまいました。 スマホ自体は端末交換してiCloudからバックアップを取り出して小一時間で復活したのですが、ここで問題が発生しました。 AWS Management Consoleには弊社社員は全員MFAを使用してログインしているのですが、そのワンタイムパスワードはスマホの「google authenticator」というアプリを使用していまして、こいつの設定はiCloudからバックアップは出来ないんです。。。 つ

はじめに こんにちは。やっと吟遊詩人で3曲歌えるようになった福田です（ダウルダヴラは無理） AWSを利用していて、利用金額が一定になったら警告して欲しいという場合があります。AWSではCloudWatchでBilling Alertが用意されており、一定ドルになったらメールを飛ばすという設定ができます。 今回はこのBilling Alertの設定をコンソリ（Consolidated Billing）環境でやってみたいと思います。 ※コンソリ環境ではリンクアカウント（子アカウント）のBilling Alert設定ができません。支払アカウント（親アカウント）側でリンクアカウントのBilling Alertを設定する必要があります。 ※非コンソリ環境（支払をまとめていない状態）でも同様の手順で設定が可能です。 Billing Alertを有効にする まずAWSアカウントの設定画面でBilling

AWS Security Blog An Easier Way to Manage Your Policies AWS recently announced a new feature of AWS Identity and Access Management (IAM): managed policies. Managed policies enable you to attach a single policy to multiple IAM users, groups, and roles (in this blog post referred to collectively as “IAM entities”). When you update a managed policy, the permissions in that policy apply to every entit

はじめに AWSを教育目的等で利用する際、利用費が高額なインスタンスタイプのEC2を起動させたくないなという場合があります。もちろん業務利用においても、オペレーションミスを防ぐために、同様の防御策を採りたいといったケースは少なく無いと思います。今回は、このような目的を達成するようなポリシーが設定されたIAMユーザーを作成したいと思います。 この記事のテクニックを利用すると特定AWSサービスの特定のAPIを特定条件でのみ禁止するようにする事ができるようになります。 GroupとUserの作成 まず最初に本記事で利用するGroupとUserを作成します。下記では「ec2-restricted」という名前でGroupを作成しています。 いったん No Permissions でGroupを作成してしまいます。権限が何もない状態です。 次に、同じ「ec2-restricted」という名前でUser

よく訓練されたアップル信者、都元です。本日は、IAMユーザやロール等に与えられるポリシーについて。 IAMは、AWSの操作に関するIDと権限を管理するためのサービスです。IAMユーザ等を作ることにより、そのIDで「誰が操作を行うのか」というアイデンティティを管理し、ポリシーによって「その主体はその操作を行う権限があるのか」を管理します。 関連エンティティの整理 IAMの世界には、ユーザ・グループ・ポリシー等のエンティティが出てきますので、まずはその関係を整理しましょう。 左の方はそこそこ理解しやすいと思います。ユーザはグループに所属でき、多対多の関係があります。ロールについては別エントリIAMロール徹底理解 〜 AssumeRoleの正体を御覧ください。 各ユーザ・グループ・ロールには、複数の「ポリシー」と呼ばれるものを0個または複数個付与できます。ポリシーというのは1つのJSONドキュメ

よく訓練されたアップル信者、都元です。今日もIAMです。 先日のエントリで、プロジェクトメンバーにはIAMユーザを配布しましょう、というプラクティスを示しました。ではそのIAMユーザの権限はどの程度与えれば良いのでしょうか、というのが今日のテーマ。先に断っておきますと、このエントリーは結論が出ません。非常に難しいです。では、いきましょう。 AWSは「よくあるポリシー」としていくつかのテンプレートを提供してくれています。 Administrator Policy Read Only Access Policy Power User Policy ... 上記の他に、UI上で様々なポリシーテンプレートが利用できるようになっています。これらの権限をいくつか見ていきましょう。 プロジェクトメンバー全員にAdministratorAccess権限を与えると… AdministratorAccessと

さて、皆様はIAMにどのようなイメージをお持ちでしょうか。プロジェクトに関わる複数人で1つのAWSアカウントを扱う時、各メンバーに配布するアカウントを作れる機能。そして、その気になればアカウントをグループ分けし、権限を厳密に管理できる機能。といったところかと思います。 上記のユースケースで出てきた主なエンティティ（要素）はUserとGroupですね。IAMのManagement Consoleで見てみると、IAMはこれらの他にRoleやIdentity Providerというエンティティによって構成されているようだ、ということがわかります。今日はRoleにフォーカスを当てて、その実態を詳しく理解します。 IAM Role IAM Roleを使うと、先に挙げたIAMのユースケースの他に、下記のようなことが出来るようになります。 IAM roles for EC2 instancesを使ってみ

Amazon Web Services ブログ: 【AWS発表】 AWS CloudTrail - AWS APIコールの記録を保存 What is AWS CloudTrail - AWS CloudTrail シリーズ第5弾は『ログファイルの取得とAmazon S3バケットへの集約』です。実際にどのようにログファイルが生成され、また取得集約が可能なのか、見て行きましょう。 目次 CloudTrailログファイルの取得 ログファイルを見つける ログファイルを扱う Amazon S3バケットへのログファイルの集約 シナリオ1. 単一アカウント/複数リージョンでのリソース集約 シナリオ2. 複数アカウント/単一リージョンでのリソース集約 シナリオ3. 複数アカウント/複数リージョンでのリソース集約 CloudTrailログファイルの取得 CloudTrailでは、ログファイルを指定のAmaz

よく訓練されたアップル信者、都元です。AWSにおけるクレデンシャルには大きく「管理コンソールにログインするためのパスワード（Sign-In Credentials）」と「APIアクセスを行うためにAPIキー（Access Credentials）」の2種類があることをご紹介しました。そして、前者Sign-In Credentialsのセキュリティを強固なものにする手段として、MFAの活用についてもご紹介しました。 本当は怖いアクセスキー しかし実は本当に怖いのは、後者Access Credentialsのセキュリティです。アクセスキーはMFAによる保護に向いていません。設定を工夫すれば、「MFAによる認証を経なければアクセスキーを使えないようにする」ことも可能です。しかし、一般的には「プログラムが使う認証情報」であることが多いため、MFAの認証コードがなければAPIが叩けない、というのは受

よく訓練されたアップル信者、都元です。アカウント認証というのはIDとパスワードによってなされるのが一般的です。パスワードは複数の文字種を使い、数字を含め、長いモノを設定する等、各種プラクティスはあちこちで議論されていますが、そもそものアカウントの数が多くなると、厳正なパスワード管理にもどこかにほころびが出てくる可能性 *1が出て来ます。 MFAによるセキュリティ向上 そういった状況で、パスワードだけに依らないセキュリティ向上の手段として、AWSではMFA（Multi-Factor Authentication - 二要素認証）に対応しています。 具体的にどういうことかというと、ログイン時には通常のIDとパスワード *2に加えて、そのログインのタイミングで手持ちのデバイス（ハードウェア）に表示されている数字 *3を入力しなければ、認証に成功しない、という認証方式です。デバイス上の数字は一定時

よく訓練されたアップル信者、都元です。前回（昨日）はAWSのクレデンシャルとプリンシパルを整理し、「開発運用スタッフ」が利用するクレデンシャルについてプラクティスを整理しました。今回はAWS上で稼働する「システム」が利用するクレデンシャルについてのプラクティスを整理しましょう。 システムが利用するクレデンシャル システムが利用するとはどういうことかといいますと、要するに「ユーザがアップロードしたファイルをS3に保存する」だとか「S3バケットに保存されたファイル一覧を取得して表示する」だとか、そういう操作をするシステムを作ることです。このようなシステムでは、APIキーを利用しますね。 AWSのAPIキーには、これもまた大きく分けて2種類があります。 long lived credentials （永続キー） short lived session credentials （一時キー） 皆さん

Dallas is the second city that Cruise is easing its way back into after pulling its entire U.S. fleet late last year.

よく訓練されたアップル信者、都元です。AWSにはIAMという権限管理のサービスがあります。AWSを専門としている我々にとっては当たり前の知識なのですが、皆さんはこの機能を上手く使えているでしょうか。 AWSにおけるクレデンシャルとプリンシパル まず、AWSにおけるクレデンシャルは大きく2種類 *1に分かれます。 Sign-In Credential：Management Consoleログインのためのクレデンシャル（要するにパスワード） Access Credentials：APIアクセスのためのクレデンシャル（要するにAPIキー） また、プリンシパル（ログインする主体、ユーザ名等）にも大きく2種類 *2があります。 AWSアカウント IAMユーザ これらの組み合わせとして「AWSアカウントのパスワード」「AWSアカウントのAPIキー」「IAMユーザのパスワード」「IAMユーザのAPIキー

よく訓練されたアップル信者、都元です。AWSを利用していると、APIキーの利用は必要不可欠です。数多くのAWSアカウントを扱っていれば、たまたまAPIキーは利用せず、管理コンソールへのパスワードだけで済んでしまうケースもあるかもしれませんが、これはごく例外的な状況です。しっかりとAWSを使いこなしている以上、APIキーを管理する機会が必ずあります。 鍵管理が大変 というわけで、皆さんは自分用のAPIキーを数多く管理しているわけですが、その管理は行き届いているでしょうか。少なくとも「失くしたｗｗｗ」なんていう事態は是非避けたいものです。大丈夫すか？ では、とあるキーがありましで、それが書き込まれている場所を全て挙げられますか？ あちこちのファイルに書き込んだりしていませんでしょうか。aws-cli用の設定ファイルはもちろん、環境変数設定用の~/.bash_profileの中、シェルのhist

cloudpackエバンジェリストの吉田真吾（@yoshidashingo）です。 昨日、DevLOVE現場甲子園2014東日本大会に参加して現場目線でのAWSセキュリティあるある的な話をして来ました。 その際にAWSのセキュリティ全般について知りたい場合に何を読めばいいか質問されたので、こちらで紹介しておきたいと思います。 AWSセキュリティセンター 1. AWSセキュリティ概要 ストレージデバイスの廃棄**の章では、ストレージデバイスが製品寿命に達した場合に、DoD 5220.22-M または NIST 800-88 に記載されている技術を用いてサニタイズを行ってから廃棄されるということが書かれています。 2. AWSセキュリティのベストプラクティス AWSの共有責任モデルを知る (1) Infrastructure servicesにおける共有責任モデル (2) Container

「AWS Black Belt Tech Webinar 2014 – Cost Explorer & AWS Trusted Advisor」レポート こんにちは、虎塚です。 普段なら水曜日のこの時間帯（18時台）は、Black Belt Tech Webinarを聴いているところですが、今週はre:Invent開催中につき、Webinarはお休みなのだそうです。re:Inventでは、サービスの機能アップデートの情報が次々と出ていて、続報が楽しみですね。 というわけで、今日は先週のBlack Belt Tech Webinarについてレポートします。先週のテーマは「Cost Explorer & AWS Trusted Advisor」でした。渋い！ でも重要ですね。 講師は、アマゾンデータサービスジャパンの舟崎さんです。すでに公式資料が公開されていますので、ご覧ください。 資料: A

はじめに こんにちは植木和樹です。AWSでは各種ホワイトペーパーなどの資料を多数公開しています。 AWS アーキテクチャーセンター | アマゾン ウェブ サービス（AWS 日本語） 今回は上記ページからダウンロードできる「AWS 運用チェックリスト（PDFファイル）」を読んでみました。運用チェックリストという名前ではありますが、AWSを利用する方は一度目を通しておくのをお勧めする内容でした。 チェックリストは大きく3つ「ベーシック」「エンタープライズ」「セキュリティ監査」に分かれています。このうちベーシックは15項目程とコンパクトにまとまっていて、簡易チェックリストとしてお手頃です。 残念ながらまだ日本語訳がされていないようですので、今回ベーシック部分だけをザックリ読んで簡単なコメントを書いてみました。 ベーシック運用チェックリスト 原文は「我々は〜〜〜を設定しています（理解しています）」

I like to start off our blog posts with the latest big thing 6to5 has achieved. We haven’t reached it quite yet, but in a few days 6to5 and 6to5-core will have been downloaded half a million times, and in a month or so it will be over a million times. There has been a bit of confusion in the past as to 6to5’s role in the JavaScript community, which can largely be attributed to its name. 6to5 was n

2015年一発目 あけましておめでとうございます。 今年は"発信"に重きを置いた一年にしたいと思ってます。 完璧より爆速を！ よろしくお願いします。 普通の働き方とリモートワーク メンバーと顔を合わせて同じ場所で仕事をする場合は基本的にはコミュニケーションが非常に取りやすいです。 改めて言うまでもないですが、メンバーは物理的に近くにいますし、同じ時間にほぼ必ず働いている、という点が良いのでしょう。 一方で社外でのプライベートなプロジェクトなどではメンバーの作業する場所、作業する時間はバラバラな場合が多いと思います。 そういったリモートワークをするときに僕個人が意識している言葉使いを書き残しておきます。 こんな言い方はせずに、こう言います 相談編 NG これ、どうしよう？ OK これ、どうしよう？個人的には○○と思うから、△△しておきます。 お願い編 NG ○○の作業をしたので確認お願いしま

【画像】 フィリピンに建てられた等身大ガンダム像が痩せすぎと話題に 1 名前： バーニングハンマー(庭)＠＼(^o^)／：2015/02/15(日) 19:08:03.76 ID:qjXNY8Kv0●.net フィリピンのジェズ・アイランド・リゾートに等身大のガンダム像が立ったそうだ。しかしその等身大ガンダムがやけに細長い！ジェズ・アイランド・リゾートの公式Facebookでも紹介されており、「19.5メートルのガンダムロボット！」と投稿している。機体は皆も知っている『RX-78-2』である。 ガンダムだけでなく『モンスターズ・インク』のキャラクターやアメリカの人気アニメ『キャットドッグ』も園内に作られているようだ。しかし一際目立つのは等身大のガンダム。しかしこのガンダムは許可を得て作られた物なのだろうか。 気になるのが股にある「J」という文字。オリジナルには無いが日本のキャラクターという

今の会社であなたの思っていることを同僚や部下、上司と話せていますか？Flatは、自分の名前を出さずに、会社のみんなとフラットに雑談できるアプリです。あなたの会社限定のルームで、気軽に投稿やコメントして雑談してみましょう！ また、Flat内のラウンジでは同じ業種の人たちと会話ができます。他の会社の人は普段どんなことを考えているのかも見ることができます。

こんにちは。小椋です。 「まあ15分ぐらいなら落ちてても実際そこまで困らないけど、基本的には24時間起動していてほしいんだよね……」 という緩めのサービスレベルで稼働しているSPOF気味なサーバー、ありますよね。社内向けのジョブスケジューラーとか、一日に数回なんか集めて分析する奴とか。あんまり表立って言わないだけで、御社にもありますよね？ サービスレベルが緩めだし、ミッションクリティカルでもないので、ただ起動しっぱなしにしてほっとけばいいや……と思いきや、やっぱり止まったら止まったで処置も必要だし、生死確認はちゃんとしないといけないし、そもそも起動しっぱなしなのでお金もかかるし、とか、意外とお金も労力もかかりますよね。 私HDEの社長ですが、サーバ代に関してはかなりケチです！ そういうケースに関しては、場合によってはEC2のAutoScaling Groupで管理すると節約ついでに横着でき

デフォルトの場合 半角英数字の文字列がboxからはみ出す。 句読点が場合よっては先頭に来ることもある。 禁則処理で望むこと 句読点が先頭で始まらない。 boxからはみ出ない。 参考サイト http://blog.sakurachiro.com/2010/06/control-break/ http://nanto.asablo.jp/blog/2013/06/18/6869571 各プロパティの説明 overflow-wrap: break-word;(CSS3草案なのでこちらを使うのが良さそう) word-wrap: break-word; 日本語：単語の途中で改行が入る。　英語:基本入らない 日本語の場合は句読点が先頭で始まらない。 冒頭のいわゆる禁則処理的な動きになると思われる。 bodyに直接指定してしまってもよさそう。 https://developer.mozilla.org/

Babel is a JavaScript compiler.Use next generation JavaScript, today. Babel 7.24 is released! Please read our blog post for highlights and changelog for more details!

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert