本講座はAmazonが提供するクラウドコンピューティングサービス「AWS」(Amazon Web Services)の入門編です。AWS上にWebサーバ環境を構築する方法について学習することができます。AWSの基本について短時間で独学できるよう作られています。 AWSは、クラウド(クラウドコンピューティング)サービスです。インターネット経由でコンピューティング、データベース、ストレージなど、さまざまな IT リソースを利用することができます。現在では多くのWebアプリケーションがAWSを利用して稼働しています。 なお、本講座は理解しやすいよう基本的な内容に留めています。また、本講座は講座作成時点での仕様に基づいて作成されています。最新の情報や、より詳細な情報の収集には公式のドキュメントなどをご利用ください。
AWS アカウントを複数人で使ってシステムを作っていく時に、 セキュリティの面からやるべきことについて。 主に Web アプリケーションを想定した内容ですが、特に書いてあることは特殊ではないと思います。 各所の Blog にも記事書かれてますが思っていることをつらつらと書いてみます。 なんか変なこと言ってたらご指摘ください。 参考: AWSのセキュリティが気になるなら読んでおくべきAWSセキュリティのベストプラクティス - yoshidashingo はじめに (AWS アカウントと IAM ユーザ) 前提というか用語の話。 AWS アカウント アカウント作成時のメールアドレス、パスワードでログインして使うユーザ IAM ユーザ AWS アカウントから発行できる、ユーザ名とパスワードでログインして使うユーザ AWS アカウント周り AWS アカウント (ルートユーザ) で作業できないように
前回の記事で EC2 と RDS によるミニマムなサーバー環境の構築手順をご紹介しました。 この環境はアプリケーション・サーバーがユーザー (Internet) からの HTTP リクエストを受け付けるだけでなく、管理者によるサーバーメンテナンスのための SSH 接続も受け付けるという構成になっています。AWS 再入門ということで、最初のお勉強としてはこれでも上出来かと思いますが、いくらミニマム構成とはいえ、これをこのまま本番運用するとなるとセキュリティの観点からイマイチよろしくありません。 ではどうするのが良いのか? そもそもアプリサーバー自体が外部から直接 SSH 接続を受け付けること自体よろしくありません。外部からのSSH接続は、アプリサーバーとは別の専用サーバーが受け付けるべきです。そしてそのサーバーからアプリサーバーにSSH接続するといった二段階接続の構えをするというわけです。し
よく訓練されたアップル信者、都元です。前回は「Amazon VPCを使ったミニマム構成のサーバ環境を構築する」と題して、Amazon VPCに小さなサーバ環境を構築しました。この環境は、アプリケーションサーバ(Webサーバ)がユーザからのHTTPを受け付けつつ、管理者によるメンテナンスのためのSSHの受け付けも兼ねている状態です。セキュリティの観点からは、あまり好ましい状態とは言えませんね。 そこで今回は、メンテナンスのための踏み台(bastion)サーバを構築し、よりセキュアな構成にしてみましょう。環境の構成図は右の通りです。まず、アプリケーションサーバはHTTPのみを受け付けるようにSecurity Groupを調整します。また、public subnetの中にもう一つサーバを起動し、踏み台として使います。こちらはSSHのみを受け付けるように調整します。踏み台サーバは常時起動しておく必
西澤です。ここのところアカウントを集約する方法を色々と調べているのですが、先日のAWS Directory Service(Simple AD)のみでユーザ管理(AWS Management Console編)で色々と方法を模索している中で、AWS Directory Serviceが用意してくれるアクセスURLでは、複数のAWSアカウントを束ねて管理することは実現できないことがわかった為、これをADFSを利用することで実現する方法をご紹介します。 設定方針 全てのアカウントはAWS Directory Service(Simple AD)上のユーザで集約して管理をします。IAMユーザは作成することなく、複数のAWSアカウントへのアクセス制御を行います。 構成 ADFSの裏で利用するDirectory Serviceは、今回もAWS Directory Service(Simple AD)
【アップデート】Amazon EC2 Systems ManagerのPatch ManagerがLinuxに対応しました!!! 森永です。 パッチ管理してますか? 古いパッケージをそのまま使っていませんか? 脆弱性を突いた攻撃の多くはパッチ管理をしていれば防げますが、後手に回っているという方も多いかと思います。 AWSではPatch Managerという素晴らしい機能があり、自動でパッチを適用することが出来ます。 こちらの機能はWindows限定の機能だったのですが、遂にLinuxに対応しました!! Amazon EC2 Systems Manager Now Supports Linux Patching 対応Liuxディストリビューション 64-Bitと32-Bitの両方に対応 Amazon Linux 2014.03, 2014.09 以降 Ubuntu Server 12.04
ベルリンのしがひです。入社して1ヶ月が経ちました。クラスメソッドでは常識の範囲でAWSが自由に使えるので、何かを覚えた中学生のように日々アレコレ試しているところです。 ここベルリンオフィスの従業員の業務端末は全てMacで、つい最近サポート用のCeleronラップトップを購入するまでWindows環境がありませんでした。軽いWindowsアプリケーションを試したいならBoot CampでOSを入れればいいのですが、少ないSSDを圧迫しますし、たまにしか使わないのに自分の端末に別OSが眠っているというのも気持ちがいいものではありません。 Windowsでストレージをかなり食うアプリケーションを使う必要があり、オンデマンドで維持費が低い環境を考えてみました。 On-Demand Windows 10 Desktop as a Service Citrix XenDesktop Essential
EC2の価格表を生成する必要があったので、その際のコードを公開します。以下をPythonで実装した感じです。 AWS各サービスの価格情報をスクレイピングするワンライナー 実行環境 Python 2.7.10 Pythonスクリプト 東京リージョンのオンデマンド価格のみ必要であったため、それ以外の情報は破棄しています。 # coding: utf-8 import json import re import sys import datetime import urllib2 def __get_price_list(url): response = urllib2.urlopen(url) # 最終行のcallbackしているJavaScript行を取得する callback_line = response.readlines()[-1] # callback処理の文字列を除去する js_
こんにちは、菊池です。 re:Inventで発表された新サービス、EC2 System Managerでは、マネージドインスタンスに登録することでオンプレミス環境の物理マシンやVMも管理することが可能です。 EC2 Systems Managerでオンプレ環境のサーバを管理する #reinvent こちらのエントリではオンプレのCentOSを管理してみました。今回はWindowsのVMをマネージドインスタンスに登録し、State Managerでコマンドを実行してみました。 やってみた 管理対象 Windows Server 2012 R2 Hyper-V上のVMとして稼働 マネージドインスタンスへの登録 VMをEC2 System Mangerのマネージドインスタンスへ登録します。Windowsの場合には下記リンクの手順で実施します。 Setting Up Systems Manager
Amazon Web Services ブログ Active Directory証明書サービス(AD CS)によるAmazon WorkSpacesマネージドデバイス認証の構成 ソリューションアーキテクトの渡邉(@gentaw0)です。Amazon WorkSpacesで、クライアント証明書によるマネージドデバイス認証が可能になりました(新機能 – Amazon WorkSpaces 用のマネージド型デバイスの認証)。マネージドデバイス認証を使用すると、あらかじめIT管理者が許可したデバイスからのみ接続を許可することで認証のセキュリティを強化することが可能になります。マネージドデバイス認証は現在、WindowsおよびMac OS Xに対応していますが、iOS、Android、Chrome OS、ウェブ、およびゼロクライアントデバイスからのアクセスをそれぞれ許可またはブロックすることも可能で
こんにちは。大阪の市田です。 今回は、下記のブログの内容を元に、踏み台サーバ経由のSSHセッションを記録する方法をご紹介します。 How to Record SSH Sessions Established Through a Bastion Host | AWS Security Blog 尚、踏み台サーバはAmazon Linuxを想定しています。 ポイント この記事のポイントは下記です。 OpenSSHの設定の修正 scriptコマンドの利用 踏み台サーバユーザの権限制限 ログファイルのS3保管 S3による踏み台サーバユーザの自動管理 SSHのエージェントフォワード利用 CloudFormationで環境構築 それでは順に説明していきたいと思います。 構成 想定の構成は下記の通りです。 ログファイルのディレクトリ作成 まずは、踏み台サーバにログの保存ディレクトリを作成し、アクセス制限
AWSクラウドデザインパターンとは? AWSクラウドデザインパターン (AWS Cloud Design Pattern, 略してCDPと呼ぶ)とは、AWSクラウドを使ったシステムアーキテクチャ設計を行う際に発生する、典型的な問題とそれに対する解決策・設計方法を、分かりやすく分類して、ノウハウとして利用できるように整理したものである。 これまで多くのクラウドアーキテクト達が発見してきた、もしくは編み出しきた設計・運用のノウハウのうち、クラウド上で利用が可能なものをクラウドデザインのパターンという形式で一覧化し、暗黙知から形式知に変換したものであるといえる。 パターンの中には、クラウドでなくても実現できるもの、今まででも実現されていたものも含まれているが、クラウド上でも今まで通りのアーキテクチャが実現でき、かつクラウドを利用する事で、より安価にそしてより容易に実現できるものは、CDPとして収
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) を利用した呼び出しが行えないことが
1度挫折したんですが、Node.js側からせめてサーバーサイドでも認証できました。 具体的なコードを(ほとんどコピーですが)以下のプロジェクトに上げました。 https://github.com/a-hisame/cognito-userpools-example cognito-idpのGetAuthenticationDetailsとAuthenticateをそれぞれ定義して使っています。 詳しくはプロジェクト内の feature-list-ja.md あたりを読んでみてください。 これで、 ユーザの生成(+確認用コード付き) ユーザのパスワードなどの再発行 ユーザの管理 アクティブユーザの閲覧 ユーザに紐付く一時IAMの発行 などがAWS Cognitoだけで完結できるようになりました *1。 すげぇ。 *1:厳密にはIAM RoleとかSTSとかをCognitoが使ってるけど、表面
はじめに こんにちは植木和樹@上越妙高オフィスです。今日はAmazon Linuxへのsshログイン時におけるセキュリティ強化のお話です。 AWS運用チェックリストではOSにログインする際のユーザーは共有せず、個人ごとにOSアカウントを作成することが推奨されています。 これからAWSを始める人は一読すべき「AWS運用チェックリスト」を読んでみた | Developers.IO 個人ごとにOSアカウントを作成すれば、いつ誰がそのサーバーにログインしたのか分かるので不正な操作が行われた際のトレースに役立ちます。 しかし仮にパソコンが盗まれる等で秘密鍵が盗まれてしまった場合を想定し、さらにもう一段階、その人のみが持っているものを用いなければサーバーにログインできない仕掛けを作ってみます。これを2段階認証といいます。今回は 1.個人のssh鍵ファイル + 2.スマホに表示されるワンタイムパスワード
onprepackの津村です。(※onprepack = 最近社内で流行ってる単語。) 地元のスーパーで柿が売られているのをみて、秋を感じています...。(しみじみ VPCのプライベートサブネットに、VPNから乗り込む。 最近はGoogleAppsやサイボウズをはじめとして、グループウェア製品は、インストールタイプからSaaSに移行しつつあります。 インターネット上から誰でもアクセスでき、サーバを用意する必要が無いSaaSでの提供は、ビジネス上のコストを上手に下げてくれる効果があります。 しかし、一方で会社によっては、秘伝のタレのごとくコードを継ぎ足し継ぎ足し作ったグループウェアから乗り換えられない(しかもスパゲッティでメンテできない)といった状況から、ミドルウェアの脆弱性やハードウェアの寿命を放置、もしくは場当たりのメンテナンスで延命している場合もあります。 例えば脆弱性のあるアプリケー
AWS VPN (1) between VPC VPN G/W and Debian Linux (racoon, setkey, quagga) with NAT AWSのVPCにはVPN機能がついているので、利用すると社内など任意のサブネットとVPCの間を、Privateアドレスで暗号化通信できるようになります。 通常このVPC VPNは、ハードウェアルーターを用いて接続するべく、一般的なルータの設定ファイルを配布してくれる至れり尽くせりな環境なのですが、ウチは貧乏でLinuxが大好きなので、 Debian Wheezyで接続を試みるのでした。 2つの方法 Linuxでは私が最初に構想した、綺麗で完全な冗長化構成はできないことがわかり、妥協案として2つの構成案ができたため、2つのエントリに分けて書くことにします。その2つの案とは、 綺麗な冗長化+NAT 泥臭い冗長化+非NAT で、まず
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く