AWS MFA(多要素認証)

– AWSのアカウント申請お願いします
→ 終わりました、MFA認証しといてね
→ え、MFAって何?
→ は? 自分で調べろよ
→ 。。。

よくある会話ではないでしょうか? ということでして、AWSのMFAを調べます。
https://aws.amazon.com/jp/iam/details/mfa/

AWSのページだと、IAM配下にありますね。
MFA (Multi-Factor Authentication)は、ユーザーとパスワードに加えて、保護レイヤーを追加。サインインする際に、認証コードの入力が必要になる。

MFAのフォームファクタ
– 仮想MFAデバイス
– ユニバーサル第2因子(U2F)セキュリティーキー
– キーホルダータイプのMFAデバイス
– ハードウェアのディスプレイカードMFAデバイス
– SMS MFAデバイス(プレビュー)
– ハードウェアのキーホルダータイプ MFAデバイスAWS GovCloud向け
なんだこれは?とりあえず、SMS MFAデバイスのことか??

公式のポリシーサンプル

{
	"Version": "2012-10-17",
	"Statement": [{
	  "Effect": "Allow",
	  "Action": "["ec2:*"]",
	  "Resource":["*"],
	  "Condition": {"NumericLessThan": {"aws:MultiFactorAuthAge": "3600"}}
	}]
}

ん?

{
	"Version": "2012-10-17",
	"Statement": [
	{
		"Sid": "AllowAllActionForEC2",
		"Effect": "Allow",
		"Action": "ec2:*",
		"Resource": "*"
	},
	{
	    "Sid": "DenyStopAndTerminateWhenMFAIsNotPresent",
	    "Effect":"Deny",
	    "Action" : [
	    	"ec2:StopInstances",
	    	"ec2:TerminateInstances"
	    ],
	    "Resource": "*",
	    "Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": false}}
	}
	]
}

EBS、インスタンスタイプの最適化

AWSのEC2のインスタンスタイプやEBSを見直したいとする。さて、どこから見直す?

まず、現状を調べるところから。
モデル、VCP, CPUクレジット、メモリ(GiB), ストレージからか。
現状把握 → 検証方法検討 → パフォーマンス測定 → レビュー → インスタンスタイプ・EBS変更 → 事後レビュー
こんなところか。 

rtc_cmos: probe of rtc_cmos failed with error -16

rtc_cmos: probe of rtc_cmos failed with error -16

Error related to time synchronization at OS startup

https://forums.aws.amazon.com/thread.jspa?threadID=87634

Re: Linux EC2 instance unresponsive! crashed?
Posted by: msloc016
Posted on: Feb 23, 2012 2:15 PM
in response to: msloc016 in response to: msloc016
 	Click to reply to this thread	Reply
I did just see that logwatch gave me this:

WARNING: Kernel Errors Present
http://2230098.568434 rtc_cmos: probe of rtc_cmos failed with error -16 ...: 1 Time(s)
http://8424538.017762 rtc_cmos: probe of rtc_cmos failed with error -16 ...: 1 Time(s)
Don't know if that means anything to anyone.

なるほどな、コミュニティのスレッドで調べるのか、勉強になります。

backup and recovery approach using AWS

Durability
Use 99.999999999% durability of safe storage of data provided by Amazon S3.

Security
Use flexible access control applicable to data transfer and storage and various encryption options.

Global infrastructure
Since it can be used all over the world, will use regions that comply with organization’s compliance requirements, local laws and regulations, standards etc.

Compliance
Since AWS complies with various security standards around the world including SOC, ISO 27001, PCI DSS, etc., it is possible to easily match the backup mechanism to existing compliance standards.

Scalability
Since a storage area that automatically changes according to the size of the backup data is provided, there is no need to manage the storage capacity

Reduced TCO
By using full managed services, operation costs are reduced, leading to a reduction in the total cost of ownership(TCO) of backup storage.

Price based on metered basis
Since it is a usage fee based on the used capacity and duration, a life cycle plan is set so that only data necessary for backup and recovery plan is saved.

169.254.169.254 port 80: Connection refused

Failed to connect to 169.254.169.254 port 80: Connection refused
ん? なんだこれは?

git hub issueを見てみましょう。
https://github.com/future-architect/vuls/issues/402
そもそもvulsってなに?
-> 脆弱性検知ツール Golangだあああああああああああああああああ
osはcentosの模様

で、issueを見ると、
>Yes, if you don’t use AWS, you can ignore this error.
awsでなければ無視していいよ、とのこと。
え、awsなら、何のエラー???

そもそも、169.254.169.254は、ping meatdata serverのことらしい。
metadata serverとは? :メタデータ環境で個別ユーザーまたはユーザーグループを表すメタデータオブジェクト?

メタデータサーバは、各データ(ファイル)の保管場所、保存方法等のメタデータ管理に利用される。

え、メタデータって何?HTMLのmetaのこと??
データの付帯情報

つまり、メタデータサーバーは付帯情報を保管しているサーバーって理解であってる?

aaaaaaaaaaaaa、なるほど

169.254.169.254にアクセスして、IPやホスト名、VPC情報などインスタンスのメタ情報が保存されている!?

169.254.169.254 port 80: Connection refused だから、インスタンスのメタ情報サーバーへのアクセスが禁止されているってことね。了解!

LinuxのCPU使用率100%と下げ方

CPU使用率とは、プログラムがどの程度CPUを使っているかとうこと。
CPU使用率が100%でないということは、CPUに遊びがあるという状態。

CPU使用率とは: 一定の時間に対して、どれだけCPUが稼働したか。
1000ミリ秒中550ミリ秒、稼働すれば、CPU使用率は55%になる。当たり前か。

CPU使用率が高いと、アプリケーションのパフォーマンスが落ちるイメージがあるが、つまり、CPU使用率は高い方がいいのか?

CPU周波数とは
1秒間で送信できる0か1のデジタル信号の数
3.2GHzのCPUの場合、Coreで1秒間に32億回0か1の信号を送って処理ができる。つまり、クロック周波数 = 最大通信回数
3.2GHzのCoreに対して、22億4千万回の信号を送って処理すると、Core使用率は70%になる。

で、AWSのCPU周波数は?
M3.Midium Maximum Capacity:3840 MB

DBインスタンスクラスの仕様
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html
ECU: Intel XeonまたはAMD Opteronの1.0G~1.2GHz相当(クロック周波数)=最大10~12億通信回数
M3.midiumが3ECU = 3.0G~3.6GHz相当のクロック周波数 = 30~36億通信回数
M3.large(6.5ECU)に上げる?

ElasticIPとPublicIP

プライベートIPv4は、インターネットから到達できないIP
プライベートIPv4は、同じネットワーク内のインスタンス間の通信に使用

RFC1918

パブリックIPアドレス インターネットから到達可能なIPv4アドレス
インスタンスとインターネット間で通信するにはパブリックアドレスを使用

Elastic IPアドレス(IPv4) : アカウントに割り当てることができるパブリックIPv4アドレス
IPv6アドレス:IPv6 CIDRブロックをVPCと関連付けることができる

プライベートIPは、要するに1つのインスタンスから別のインスタンスに接続する際に使用するIPアドレス

プライベートIPとパブリックIPはサーバを再起動すると変わるが、ElasticIPは固定できる。

AWS 踏み台サーバー(bastion)経由でSSH接続

踏み台サーバーの英語:bastion
英語名のbastionをそのままAWSのインスタンス名に使用することが多いかと思います。

踏み台サーバのセキュリティ
踏み台サーバーは、例えば アクセスする地域が限定されていてアクセスできない場合に、許可されている地域のサーバ経由でアクセスするなど、悪いイメージがあるかもしれませんが、アプリケーションのセキュリティ対策としては有効な手段の一つとなっています。

踏み台サーバーとは?
踏み台サーバーとは中継サーバーで、踏み台サーバーを経由してでないとターゲットのサーバーにアクセスできないようセキュリティグループを設定する。
踏み台サーバーからアクセスすれば、接続先のWebサーバに踏み台サーバから接続してきたと思わせることができる。

– パブリックIPをインスタンスに割り当てる必要がない
– アクセス制御の対象を踏み台サーバに限定できるため、運用負荷を軽減

AWSでの設定方法
1. VPCの作成
2. Subnetの作成(踏み台サーバ、アプリサーバ、データストア)
3. Internet Gateway
4. Route Tableの確認、設定
5. Security Groupの作成(踏み台サーバ、アプリケーションサーバ、DB用)
6. 踏み台サーバの構築

※セキュリティグループをそれぞれ作成する

VPCのセキュリティグループ

– セキュリティグループは、インスタンスの仮想ファイアウォールとして機能し、インバウンドトラフィックとアウトバウンドトラフィックをコントロール
– VPC 内でインスタンスを起動した場合、そのインスタンスには最大 5 つのセキュリティグループを割り当てることができる
– 起動時に特定のグループを指定しないと、インスタンスは VPC のデフォルトのセキュリティグループに自動的に割り当てられる

AWS「ネットワーク&セキュリティ」の「セキュリティグループ」を見ます。

セキュリティグループとは
インバウンド
送信元 プロトコル ポート範囲 コメント

アウトバウンド
送信先 プロトコル ポート範囲 コメント

SSHをAnywhere(0.0.0.0/0)に対して開放し、万一キーペアが流出してしまった場合、クラッキングを受けた場合、SSHに脆弱性が発見された場合など、
様々なリスクがある。

なるほど、セキュリティグループ(VPC)でインバウンド、アウトバウンドを制御しているのね。