タグ

2016年6月13日のブックマーク (17件)

  • Amazon S3 のアイデンティティベースのポリシー例 - Amazon Simple Storage Service

    このセクションでは、Amazon S3 へのユーザーアクセスを管理するための AWS Identity and Access Management (IAM) アイデンティティベースポリシーをいくつか示します。バケットポリシー (リソースベースのポリシー) の例については、「Amazon S3 のバケットポリシー」を参照してください。IAM ポリシー言語については、「Amazon S3 のポリシーとアクセス許可」を参照してください。 次のサンプルポリシーは、プログラムで使用する場合に機能します。ただし、Amazon S3 コンソールでこれらを使用するには、コンソールに必要な追加のアクセス許可を付与する必要があります。このようなポリシーの Amazon S3 コンソールでの使用の詳細については、ユーザーポリシーを使用したバケットへのアクセスの制御 を参照してください。 バケット の 1 つへ

  • 署名付き URL を使用する - Amazon CloudFront

    署名付き URL には、有効期限切れ日時など、追加の情報も含まれており、コンテンツへのアクセスをより詳細に制御できます。この追加情報は、既定ポリシーまたはカスタムポリシーに基づくポリシーステートメントに含まれます。既定ポリシーとカスタムポリシーの違いを以下の 2 つのセクションで説明します。

  • Amazon Cognitoによる認証はSTSのweb identity federationとどう違うのか!? | DevelopersIO

    Amazon Cognitoによる認証はSTSのweb identity federationとどう違うのか!? よく訓練されたアップル信者、都元です。少し前の話になりますが、2014年7月に Amazon Cognito がローンチしました。Cognitoは、モバイルアプリのためのサービスで、弊社ブログでも何度か取り上げています。 Cognitoの機能は、実は「Cognito Sync(複数デバイス間のデータ同期)」と「Cognito Identity(ID管理)」という2つのカテゴリに分類されます。もしかしたら、元々は別のプロダクトだった感もあります。というのも… APIドキュメントが別 Amazon Cognito Identity Amazon Cognito Sync AWS SDK for Javaのクライアント実装が別、Javaパッケージも別 com.amazonaws.se

    Amazon Cognitoによる認証はSTSのweb identity federationとどう違うのか!? | DevelopersIO
  • Amazon API Gateway & Lambda & S3 で放置可能なサービスを作ってみた - Qiita

    1年半ほど前に書いたこちらの記事、タイミングが良かったのか naoya 砲なのか分かりませんが、色んな方に読んで頂けたようです。 しかし、「放置可能なサービス」というタイトルに反し、この記事で作成した楷書体サービス、とうとうメンテを行うことになりました。 理由は、node v0.10 のサポートを Lambda が打ち切るためです。 コードそのまま node v6 で動かせるとは思いますが、それでも放置できなかったことには変わりありません。謹んでお詫び申し上げます。 いやまぁ1年半もメンテナンスせずに動いてたんだからすごいじゃんと思う。今クリックしたら普通に動いてびっくりした また、近年 serverless や microservices の流れがあったり、 GCP も Azure も対抗サービス出したりして、LambdaAPI Gateway を取り巻く環境は大きく変わりました。

    Amazon API Gateway & Lambda & S3 で放置可能なサービスを作ってみた - Qiita
  • NGINX Documentation

    Available in Early Access. Monitor your infrastructure, address security vulnerabilities, and assess the health of your NGINX fleet, all from a single console.

    NGINX Documentation
  • mod_proxy再入門 – ProxyPassとProxyPassReverse | DevelopersIO

    こんにちは。望月です。 思い返すこと数年前、私が始めてLinuxサーバ構築に関わってやったお仕事は、「Apache + Tomcatの構成を作る」でした。その時にApacheに以下のような設定をしました。 ProxyPass /app http://backend.example.com:8080/ ProxyPassReverse /app http://backend.example.com:8080/ それ以降Apacheをフロントに置いて別のアプリケーションサーバーへProxyを行う機会は何度となくあり、その度に魔法のようにProxyPassとProxyPassReverseを書いてきましたが、自分で理解しきっていない設定をするのは止めよう、と思い立ったので、改めてmod_proxyについてお勉強してみました。今日はその勉強過程をまとめます。 ProxyPass まず一行目のPro

    mod_proxy再入門 – ProxyPassとProxyPassReverse | DevelopersIO
  • S3+EC2でBasic認証を設定をする - Qiita

    やりたかった事 S3にBasic認証をかけてみたかったので、試してみました。 S3+EC2構成で、Basic認証を行います。 今回の環境 ・EC2( Amazon Linux AMI release 2015.09 ) 自分が接続する拠点からの、http(80番)・SSH(22番)のアクセスを許可 ・S3バケット S3バケットを1つ作成する(今回は s3.k-staging.com というバケット名で作成) ウェブサイトのホスティングを有効にしておく ・Route53 ドメイン「 s3.k-staging.com 」を発行する TypeはCNAMEで、Valueには上記EC2のPublic DNSを設定する S3バケット設定 バケットポリシーを以下のように設定します。 { "Version": "2012-10-17", "Id": "PolicyXXXXXXXXXXXXX", "Stat

    S3+EC2でBasic認証を設定をする - Qiita
  • Amazon,S3にてBasic認証をかける - Qiita

    S3で静的サイトをホスティングする、Static Website Hosting。 便利で高性能だが、Basic認証がかからない。 リバースプロキシを介することで対応してみる。 リバースプロキシサーバがボトルネックとなり、せっかくのStatic Website Hostingの性能も生かせないが、とりあえずやってみる。 描くまでもないが、構成はこんな感じ。 以下、手順。 ① webサーバでリバースプロキシの設定を行う。 <IfModule mod_proxy.c> ProxyPass /hoge http://xxx.s3-website-ap-northeast-1.amazonaws.com/app ProxyPassReverse /hoge http://xxx.s3-website-ap-northeast-1.amazonaws.com/app </IfModule>

    Amazon,S3にてBasic認証をかける - Qiita
  • 特定のS3のフォルダにのみアクセス権のあるIAMユーザーを使ってCyberduckから参照する | DevelopersIO

    特定のS3のフォルダにしかアクセス権を与えたくない場合、 ポリシーを作成してIAMユーザーに付与し、そのユーザーからフォルダを参照しますが、 マネジメントコンソールから入るとトップページを表示する権限がないので以下のメッセージが表示され目的のフォルダにアクセスできません。 そのため今回は、S3のフォルダおよびそこにしかアクセス出来ないポリシーを作成し、そのポリシーを付与したIAMユーザーのクレンデンシャル情報を使ってCyberduckからアクセスする方法を紹介します。 手順 手順は以下になります。 フォルダの作成 ポリシーの作成 IAMユーザの作成 Cyberduckの設定 1.フォルダの作成 S3のコンソールから「バケットを作成」ボタンをクリックし、バケット名とリージョンを選択してバケットを作成します。 この時にバケット名の命名ルールに準じていないとバケットが作成出来ないので注意しましょ

    特定のS3のフォルダにのみアクセス権のあるIAMユーザーを使ってCyberduckから参照する | DevelopersIO
  • IAM ポリシーエレメント: 変数 - AWS Identity and Access Management

    序章 IAM ポリシーでは、アクセスを制御する特定のリソースに対して名前を指定することが多くのアクセションで許可されています。例えば、以下のポリシーでは、ユーザーは、marketing プロジェクトの S3 バケット DOC-EXAMPLE-BUCKET 内のオブジェクトの一覧表示、読み取り、および書き込みができます。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:ListBucket"], "Resource": ["arn:aws:s3:::DOC-EXAMPLE-BUCKET"], "Condition": {"StringLike": {"s3:prefix": ["marketing/*"]}} }, { "Effect": "Allow", "Action": [ "s

  • 【IAM TIPS】S3バケット毎に権限を分けるためのIAM権限設計 | Developers.IO

    望月@シアトルです。 今日はAmazon S3を複数名で利用するときの、IAM権限制御に関するTIPSのご紹介です。 想定する環境 S3は安価かつ高耐久性のストレージとして、AWS上でシステムが稼働しているかどうかに関わらず利用することが可能です。また、単純な保存領域としてだけでなく、S3 Static Website Hostingと呼ばれる機能を利用すれば、S3にHTMLなどの静的ファイルを配置しておくだけで簡単にWEBサイトを作れます。 この機能により、可用性・対障害性の高いWEBサーバを非常に安価(〜10円/月)でホスティングできます。 Static Website Hostingを利用する時には、S3にファイルを配置するだけで外部への公開ができますが、気にしなければならないことの一つに権限の管理があります。S3へのアップロード権限はAWS Identity and Access

    【IAM TIPS】S3バケット毎に権限を分けるためのIAM権限設計 | Developers.IO
  • IAM アイデンティティベースのポリシーの例 - AWS Identity and Access Management

    ポリシーは AWS のオブジェクトであり、アイデンティティやリソースに関連付けて、これらのアクセス許可を定義します。AWS は、IAM プリンシパル (ユーザーまたはロール) によってリクエストが行われると、それらのポリシーを評価します。ポリシーでの権限により、リクエストが許可されるか拒否されるかが決まります。通常、ポリシーは、IAM エンティティ (ユーザー、ユーザーのグループ、ロール) にアタッチされている JSON ドキュメントとして AWS に保存されます。アイデンティティベースのポリシーには、AWS 管理ポリシー、カスタマー管理ポリシー、およびインラインポリシーがあります。これらの例の JSON ポリシードキュメントを使用して IAM ポリシーを作成する方法については、「JSON エディターを使用したポリシーの作成」を参照してください。 デフォルトではすべてのリクエストが拒否され

  • Amazon API Gateway の API を Cognito で認証して呼び出す | DevelopersIO

    API を IAM で認証する Amazon API Gateway (以下 API Gateway) で作成した API は、誰でも呼び出せるように公開する他に、2つの認証方法が用意されています。 API Key をヘッダーに付与する方法 (こちらで解説) IAM で認証する方法 この2つの方法のうち、今回は IAM で認証する方法を試してみたいと思います。 API Gateway にはモバイルアプリ向けの SDK を生成する機能がある点から、モバイルアプリを主なターゲットにしているように思えます。そこで、Amazon Cognito (以下 Cognito) を利用した認証方式を通して API Gateway で作成した API を呼び出してみたいと思います。 先日まで生成した SDK の認証周りでエラーが発生し Cognito (IAM Role) を利用した呼び出しが行えないことが

    Amazon API Gateway の API を Cognito で認証して呼び出す | DevelopersIO
  • ウェブサイトエンドポイント - Amazon Simple Storage Service

    バケットを静的ウェブサイトとして設定すると、そのウェブサイトは、バケットの AWS リージョン 固有のウェブサイトエンドポイントで利用できます。ウェブサイトエンドポイントは、REST API リクエストを送信するエンドポイントとは別のものです。エンドポイントの違いの詳細については、「ウェブサイトエンドポイントと REST API エンドポイントの主な違い」を参照してください。 使用しているリージョンに応じて、Amazon S3 ウェブサイトエンドポイントは以下の 2 つの形式のいずれかになります。 s3-website ダッシュ (-) リージョン ‐ http://bucket-name.s3-website-Region.amazonaws.com s3-website ドット (.) リージョン ‐http://bucket-name.s3-website.Region.amazon

  • ログイン・ログアウト機能をサーバレスアーキテクチャで実装する - Qiita

    ※実運用では、登録日などの項目も持たせて、セッションタイムアウト時間も設けたほうが良いです。 Lambdaファンクション ログイン処理 入力値として、emailとパスワードを受け取ります。 ログインに成功すればセッションIDを返します。webシステムで使う場合はこのセッションIDをcookieに保存して引き回してあげましょう var aws = require("aws-sdk"); var doc = require('dynamodb-doc'); var crypto = require('crypto'); var dynamo = new doc.DynamoDB(); exports.handler = function(event, context) { if ( typeof event.email === 'undefined' || typeof event.passw

    ログイン・ログアウト機能をサーバレスアーキテクチャで実装する - Qiita
  • Amazon Cognito User Poolsを使って、webサイトにユーザ認証基盤を作る - Qiita

    概要 AWS Summit 2016 Chicago にてAmazon Cognitoの新機能として発表された「User Pools」を使ってwebサイトにユーザ認証基盤を作ります。User Poolsはサインインやサインアップ、セッション管理など、よくあるユーザ管理機能をマネージドで提供してくれるサービスです。 [New] Amazon Cognito 向け User Pools User Poolsの作成 [新機能] Amazon Cognito に待望のユーザー認証基盤「User Pools」が追加されました! 作成方法についてはClassmethodさんのブログに詳しく乗ってますので参考にしてください。 JavaScriptからUser Poolsの認証機能を使う時の注意点として、以下のAppsの作成でGenerate client secretのチェックを外してください。Java

    Amazon Cognito User Poolsを使って、webサイトにユーザ認証基盤を作る - Qiita
  • 【AWS】Amazon S3をFTP/SFTPサーバーのように使ってみた | DevelopersIO

    今回の課題 こんにちは植木和樹です。日のお題は「現在運用しているFTP/SFTPサーバーをAmazon S3でリプレースしたい」です。 外部関係業者とのファイルのやりとりにFTP/SFTPサーバーを使っているケースは数多くあると思います。社内にあまったパソコンにLinuxをインストールしてFTPサーバーを自前で運用していることもあるかもしれません。しかしデータのバックアップやハードウェアの故障などで手を取られている担当者の方がいらっしゃるのではないでしょうか。 そんな時はAmazon S3。99.999999999% の堅牢性と、99.99% の可用性を提供するストレージサービスです。 しかしFTPは長い運用実績の歴史があるサービスです。FTPで求められる様々な運用ニーズにS3はどこまで応えられるでしょうか?今回はその点を検証してみました。 FTPに求められる要望 以下にいくつかの代表的

    【AWS】Amazon S3をFTP/SFTPサーバーのように使ってみた | DevelopersIO