カテゴリー: AWS

AWS Custom VPC 作成

VPC作成手順は
VPCネットワーク作成
Subnet作成
Route Table 作成
Internet Gateway 作成
Network ACL 設定
Security group 設定
となる

まずはVPCネットワークの作成

VPCで稼働する予定の
private network Address の範囲を指定する

なお、VPCネットワークアドレスは
一度設定すると後から変更できないので余裕をもって範囲設定すること

作成するにはAWSコンソールにログインし
ネットワーキング項目のVPCをクリック

次にダッシュボードのVPCをクリックし
VPCの作成をクリック

するとVPC作成画面になります

ネームタグには任意の名前をつけます
今回なら
AWS_wpservice
とします

次に、CIDR ブロック
これはIPアドレス範囲の指定です
最大が
10.0.0.0/16
となり、 65536 IPが最大となります

テナンシーはホストサーバーの指定に関しての設定
通常はデフォルトでOK
これを
ハードウェア占有にすると
占有状態となりセキュリティなどで
他とは共有できないときに指定します
ただし、料金が割高になります

設定ができたら、作成をクリックすれば
VPCが作成されます

次に、EC２でパブリックDNSを使うため
DNSホスト名を　はい　に変更します

作成したVPCを右クリックし
DNSホスト名の編集を選択します

ダイアログがでたら
はい
を選択し、保存します

これで設定が反映されます

つぎはサブネットの作成になります

これをつくることで、複数のネットワークを作成できます
これを行うことにより
VPC内部で役割に応じたネットワーク構築ができます

サブネットの作成は
ダッシュボードからサブネットをクリックし
サブネットの作成をクリックします

するとサブネット作成画面がでてきます
ネームタグは、VPCと同じように
任意のものでOKです
今回はAWS_subnet とします

VPCには、作成した カスタムVPCがセットされます

アベイラビリティゾーンは
サブネットを作成するAZの指定になります
つまり、リージョン指定
指定しないと任意のものになります

CIDR ブロック
は
ネットワーク範囲になります

ただし
最初の４IPと、最後の１IPはAWSで使うため
利用できないし
ELBを作るには２０IP必要なため
/28 つまり 16IPではELBが使用不可のため
最低でも/24 （２５６IP）以上にしたほうがよいなど
色々と制限があるため注意が必要です
今回は
CIDRブロックは
10.0.0.0/24
としました

これでサブネットが作成されたので、
できたサブネットを右クリックし
自動割り当てパブリックIPの変更を選択します

ダイアログがでるので
自動割り当てパブリックIPを有効化
にチェックをいれて保存します

これでDefault VPC の特殊設定にある
EC２インスタンス生成時に
パブリックIPアドレス
DNSホスト名を自動設定できるようになりました

次回、RouteTable の作成になります

aws CLI の設定

 aws configure

を実行すると
対話形式で入力することで設定ができます

AWS Access Key ID [None]:
となるので
以前ダウンロードした
credentials.csv
を参考に Access Key Idを入力します

次に

AWS Secret Access Key [None]: 

となるので
AWS Secret Access Key を
crendials.csv を参考に入力します

Default region name [None]:

となるので、デフォルトで使用するリージョンを設定します

AWSのリファレンス・リージョンとエンドポイント
http://docs.aws.amazon.com/ja_jp/general/latest/gr/rande.html
の
AWS Config
にリージョン名が載っているので
今回は東京リージョンを指定するので
ap-northeast-1
とします

Default output format [None]: 

となり実行結果出力形式の指定になるので
今回は text にします

ちなみに
text だとシェルスクリプトの実行結果のようになり

json ならJSON形式

table にするとテーブル形式になります

設定が完了したら、AWS　CLIの参照コマンドを実行

まずはEC２のデフォルトセキュリティグループの参照

aws ec2 describe-security-groups

を実行すると
EC２のデフォルトセキュリティグループの参照ができます

なお AWS CLI の設定ファイルは
ホームディレクトリの .aws に保存されます

ll .aws/

とすると

drwxrwxr-x  2 snowpool snowpool  4096  9月  9 22:20 ./
drwx------ 89 snowpool snowpool 73728  9月  9 22:20 ../
-rw-------  1 snowpool snowpool    48  9月  9 22:20 config
-rw-------  1 snowpool snowpool   116  9月  9 22:20 credentials

となります

config には
出力形式の指定と
使用するリージョンの指定

credentials には
Access key ID
Secret Access Key
の値が保存されています

AWS　CLI　は基本的に

aws サービス名　操作コマンド

というようになります

IAMユーザパスワード設定

IAMアカウントとグループの紐付けはできましたが
まだパスワードなどが設定されていません

まず、パスワードのルールを設定します

アカウント管理をクリックすると
パスワードポリシーがでるので
ここで設定を行い、
パスワードポリシーの適用をクリックします

次にユーザをクリックし
一覧から選びます

下にスクロールして
パスワードの管理をクリック

パスワードポリシーに基づきパスワードを作ってもらえるので
自動生成パスワードの割り当て
にチェックをいれ

次回のサインインで新しいパスワードを作成するようにユーザーに求める
にチェックをいれ
適用をクリックします

するとパスワードが自動生成されます
作成されたパスワードは
ユーザーのセキュリティ認証情報を表示
をクリックするとみることができます

パスワードを確認したら
認証情報のダウンロード
をクリックします
このダウンロードしたファイルにも
パスワードはかかれています

ファイル名を
IAMcredentials.csv
として保存します

これでパスワードの設定ができました

IAM グループの作成

IAMアカウントにポリシー付与する場合
方法は２つ

１、アカウントに直接ポリシーを付与

２、ポリシーを付与したグループをつくり、そこに所属させる

管理の面からすると、グループ管理の方が楽

IAMグループをつくり
所属するユーザを調べるほうが効率よく管理できる

メンバーの入れ替えとかで
ユーザ追加するとき
管理者グループ
アプリ用グループ
インフラグループ
となっていれば
どの権限を付与するか
と悩まなくてもよくなるため

グループの作成については
AWSで AmazonLinux の設定

で設定したものを使います

グループをクリックし
作成しておいた
Administrators
をクリックします

下にスクロールすると
ポリシーのアタッチがあるので、クリック

ポリシー一覧が表示されるので
IAMポリシーの設定

で設定した
カスタムポリシーを選びます
なお、カスタマイズして作成したものには
AWSのアイコンがないのでわかりやすいと思います

チェックをいれたら
ポリシーのアタッチをクリックします

これでポリシーが追加されました

ただし、グループ追加だけでは意味がないので
そこに所属するユーザを追加します

これにより権限の管理が簡単になります

グループにユーザを追加
をクリックします

ユーザ一覧が現れるので
そこから選んで、ユーザの追加をクリックします

これでグループにユーザが追加されます

IAM ポリシー作成（Customer Managed Policies)

ポリシーには
Managed Policies
Inline Policies
の２つがあり

この２つはさらに細かい分類ができます

Managed Policies は
AWS Managed Policies
と
Customer Managed Policies
の２つになります

基本的に細かい設定がいらないのなら
AWS Managed Policies を使います
これはAWSのほうで設定したポリシーになります
このため権限の設定変更はできませんし
AWSが変更すれば、それにしたがうことになります

これに対して
Customer Managed Policies は
ユーザが定義するポリシーです
特定IPのみ操作をできるような設定は
こちらのポリシーを使うことになります

この２つのポリシーは、複数のユーザ、グループを
対象に行えます

Inline Policies の場合
特定ユーザのみに適用するときに使います

なお、ポリシーをユーザ定義で行う場合
JSONで記述することになります

POlicy Generator を使えば
すべて記述することはなくなります

今回は、Customer Managed Policies を作成します

これは、
AWS Management Policies は
楽なのですが、アカウントを管理するなら
自分で設定できたほうが後々便利だと思うからです
今後、自分で運用するときに困らないように
というのもありますが

まず
AWSコンソールから
Identity & Access Management
をクリック

次にポリシーをクリック

ポリシーの作成をクリック

AWS管理ポリシーをコピーを選択します

するとポリシー一覧がでます
今回は管理者権限をもつポリシーにしたいので
AdministratorAccess
を選択します

ポリシー名と説明を、自分なりにわかりやすいものに
変えて
ポリシーの作成
をクリックします

なお、ポリシードキュメントは
JSONで記述されています

これでカスタムポリシーが作成されます

なお、ユーザが作成したポリシー名には
AWSマークがついていないのでわかりやすいと思います

AWS　IAM アカウントの設定

AWSユーザアカウントが root アカウント
IAM アカウントは、サーバのユーザアカウントに該当

基本的にサーバー操作と同じで
root アカウントで作業せず
IAMアカウントで操作することになります

今回は、このIAMアカウントを作成します

まずAWSマネジメントコンソールで
Identitiy & Access Management
をクリック

次に、ユーザをクリックします

新規ユーザの作成をクリック

ユーザ名を入力し
ユーザごとにアクセスキーを生成
にチェックが入っているのを確認し
作成をクリック

これでアクセスキーのダウンロードができます
認証情報のダウンロード
をクリックすれば
アクセス情報が記載されたCSVファイルがダウンロードできます

なお、
ユーザーのセキュリティ認証情報を表示
をクリックすると
アクセスキー
シークレットキー
を表示することができます

これでユーザは作成されましたが
まだ権限がないので、なにもできません

mysql でユーザを作成したけど
権限つけていないようなものです

権限はポリシーで管理され
これは
Managed Policies
Inline Policies
の2種類になります

次回、このポリシー設定を行おうと思います

AWS の MFA 設定

MFAは
Multi
Factor
Authenication
の略名

これは、最近のIDとパスワードの設定だけだと
セキュリティが突破されてしまうため導入されたもの

基本的にAWSにログインしているアカウントが
root アカウント扱いで、AWSをコントロールすることになる

でも、これをとられるということは
サーバーの root権限をとられるようなもの

もしこれをとられると知らない間に使用料金が増える
というまさにクラウド破産になっていまいます

このためMFAを使った２要素認証を設定します

今回の設定は

のMFA設定

そしてデバイスの認証コードに関しては
IAMの使い方: バーチャルMFAを設定してみた

を参考にさせていただきました

このような２段階の認証は
Google アカウントなどでも設定することがあります

楽天銀行の場合だと
ID、パスワード以外に
ワンタイムパスワードを使用しています

なお、MFAは AWSユーザだけでなく
IAMアカウントにも設定できます

MFAを使うには認証コードを発行するデバイスが必要です

MFAデバイスは
アプリなどを使った仮想MFAデバイスと
実際に端末を購入するタイプの
ハードウェアMFAデバイスがあります

ちなみに、ハードと仮想のMFAについては
Multi-Factor Authentication

に詳細が掲載されています

ハードだと値段は
12.99 USD から 19.99 USD になります

さすがにハードウェア購入するのは
結構お金がかかりますので
今回は仮想MFAアプリを使います

使用するのは Google 認証システムというアプリです
これなら iPhone Android どちらでも使えます

今回はAndroid で行います
https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2

インストールできたら、次にAWSのコンソール画面から
設定していきます

セキュリティ＆アイデンティティ
の中の
Identitiy & Access Management
をクリックします

するとセキュリティステータスが表示されます

すでにいくつか設定がしてありますが
まず root アクセスキーを削除しておきます

これはいくら MFA を設定しても
root アクセスキーが漏れていると意味がありません
公開鍵認証を設定しても
鍵がもれているようなものです

ルートアクセスキーの削除をクリックし
セキュリティ認証情報の管理をクリックします

次にダイアログの
セキュリティ認証情報に進む
をクリックします

次に、セキュリティ認証情報の中の
アクセスキー（アクセスキーIDとシークレットアクセスキー）
をクリックし
存在するキーを削除します

削除すると緑色のチェックがつくので
次に
ルートアカウントのMFAをアクティブ化
をクリック
MFAの管理
をクリックします

ダイアログが表示されるので
仮想MFAデバイスを選び
次のステップをクリックします

デバイス管理について説明がでます
読んだら、次のステップをクリックします

認証のための画面になりますので
QRコードを読み込んで
認証コードを入れたら
仮想MFAのアクティブ化をクリックします

今回は Android で行います
アプリを起動したら
アカウントを設定 > バーコードをスキャン
を選択してQRコードを読み込みます

すると６桁の数字がでるので
最初の欄に入力します

少しまつと数字が変わるので
この認証コードを
2番めの欄に入力します

これで認証がされます

もし、画面で緑チェックがついていない場合、
一度ダッシュボードから
Identitiy & Access Management
を選択すると反映されます

実際に反映されているかを確かめるため
別のブラウザをつかって検証します

まずは今までと同じようにログインします

すると次にAuthenication Code の入力を求められるので
認証システムアプリに表示されている
認証コードを入力し
Sign in using our secure server
をクリックし、サインインします

これで2段階認証が設定されました

AWS のサーバー増設
#12 サーバーを増設してみよう (1)
http://dotinstall.com/lessons/basic_aws/9512
を参考に、サーバーの増設方法を学習
まず、稼働させている webサーバーのイメージ作成
これをもとにインスタンスを
もう一つ作成
中身は同じになるので
RDSにも繋がる
そして、アクセスをこの新しく増設したサーバーにも
できるようにして負荷分散できるようにするには
ロードバランサーを使う
実際に行うのは
#13 サーバーを増設してみよう (2)
http://dotinstall.com/lessons/basic_aws/9513
になる
やりかたは動画でもあるけど
自分なりにメモ
まず、稼働しているインスタンスを右クリック
Create Image(EBS AMI) を選択
Image Name を入力し作成
状態がavailable になったら
インスタンスを起動
#14 ロードバランサーを設置しよう
http://dotinstall.com/lessons/basic_aws/9514
でロードバランサーの設置
ロードバランサーの作成は
NETWORK & SECURITY の中にある
Load Balancers
で作成
Load Balancer Name に
ロードバランサーの名前を入力
Configration Options
は死活監視
この Ping Path に設定したものが落ちているなら
そちらには流さないという設定をする