おっさん社内SEエンジニアの勉強ブログ

勉強記録のブログとなります。

SAA学習-Day1対応-part3(AWS CloudTrail)

今日は久しぶりに雨なので湿度が改善されてよいかな

というプラス思考でとらえていきます。

 

今日のテーマ:Day1対応-AWS CloudTrail

 

ということで今日のテーマです。

 

AWS CloudTrailとは?

AWSユーザの操作をロギングするサービスになります。

 

AWSユーザの操作項目

APIコール

・ユーザのサインインアクティビティ

 

ポイント

・ルートアカウントIAMユーザの操作とAPIコールをトラッキングしてログを取得するサービス

・CloudTrailログファイルは暗号化されS3に保管

・KMSによる暗号化もサポート

・デフォルト設定で90日間ログが保管される。

・有効化するだけなら無料(※一定量は無料ですが別途かかります。)

 

AWS CloudTrailを有効化するまでをまとめていきます。

 

・マネージドコンソールより、AWS CloudTrailで検索します。

f:id:In-houseSE:20210202083042p:plain

 

イベントの履歴はログインしている

AWSアカウントで使用したイベント(コンソールへサインインなど)の履歴になります。

f:id:In-houseSE:20210202083325p:plain

 

Insightsはログの解析結果などの連携となります。

f:id:In-houseSE:20210202083508p:plain

 

証跡は実際にログとして残す証跡の作成で使用します。

 

基本的にはダッシュボード、イベント履歴、Insightsの3つを活用します。

CloudTrailを有効化するまで以下の3ステップになります。

・証跡属性の選択

・ログイベントの選択

・設定内容の確認

 

・証跡属性の選択

証跡名:admin-log 

→ 操作ログなどの保管名

証跡ログバケットのフォルダ:admin-log-202102020

→ 自分でわかるように任意の名前

ログファイルのSSE-KMS暗号化:チェック外す

→ 専用の暗号化キー作成が事前に必要なので今回は外します。

ログファイルの検証:チェック入れる

→ ログファイル自身の優位性の検証とります。

SNS通知の配信:チェック入れる

→ メール通知などをする際に必要な項目となります。

新しいSNSトピック:新規

SNSトピック:任意の値

→ 指定のトピック名があるならばそちらを設定するのが習わしになります。

CloudWatch Logs:チェックなし

→ 自己学習では不要ですが、業務ですと監視項目を有効化する必要があるため、チェックを入れて有効化することが多数です。

タグ:任意

→ 今回は1つのみしか作成しないため、未設定とします。

 

画面は未設定の状態になります。(上記を入力していき変化を楽しんでいただければ幸いです。)

 

・設定を有効化したら次へをクリック

f:id:In-houseSE:20210202083808p:plain

 

f:id:In-houseSE:20210202083842p:plain

 

・ログイベントの選択

 どのイベント単位で実行されたログのイベントを有効化するか選択となります。

管理イベント:チェック入れる

→ AWS リソースで実行された管理オペレーションをキャプチャします。

データイベント:チェック入れる

→ リソース上またはリソース内で実行されたリソース操作をログに記録します。

Insightsイベント:チェック入れる

→ アカウントの異常なアクティビティ、エラー、またはユーザーの動作を特定します。

データイベント:すべて デフォルトのまま

→ 取得したログのフィルタした結果を残す場合は別途フィルタを定義します。

 

・設定を有効化したら次へをクリック

f:id:In-houseSE:20210202084936p:plain

 

f:id:In-houseSE:20210202085143p:plain

 

f:id:In-houseSE:20210202085203p:plain

 

・設定内容の確認

 

 ・今まで設定した内容を確認してから証跡の作成をクリック

 

f:id:In-houseSE:20210202085508p:plain

 

f:id:In-houseSE:20210202085526p:plain

 

 

作成した後よくあるあるのことですが、

作成するリージョン(地域)が東京と指定しているになぜか海外のリージョンで作成しているなどがあります。

なので右上の作成する地域に関してはちらっと見てから作業するとよいです。

 

今回のテーマは以上です。

AWS認定学習記録-Day1対応-part2(管理者用IAMユーザー)

今日のテーマ:Day1対応-管理者用IAMユーザーを作成する。

 

全開は多要素認証について記載させていただきましたが、

ちょっと昔の場合ですとAWSより「パスワードポリシーを変更してください」がありますので、ご参考程度になります。

 

・IAMの画面より、アカウント設定を選択し今の画面ですと「Change」をクリック

f:id:In-houseSE:20210201072807p:plain

 

・パスワードポリシーの設定変更画面の参考はこちらです。

f:id:In-houseSE:20210201072850p:plain

 

ただ、現在はあまりパスワードを定期的に変更しても逆にセキュリティ的にはよくないのではという観点もあり、定期的にパスワードを更新しない方針がよいかもしれないという事例もあります。

 

補足事例はここまでとして、本日のテーマになります。

AWSマネイジメントコンソールのIAM画面に行きます。

・IAMユーザを新規に作成して、IAMポリシーにより管理者権限を設定します。

・IAMユーザーにログインします。

 

ダッシュボード上の補足

IAMリソース:今使用しているIAMのリソースの項目についてのサマリー

f:id:In-houseSE:20210201073349p:plain

 

ベストプラクティスAWSより推奨されているセキュリティの設定推奨内容

f:id:In-houseSE:20210201073515p:plain

 

最新機能:IAMのマネイジメントサービスが定期的に更新されるのでそのリリース内容

f:id:In-houseSE:20210201073647p:plain

 

IDプロバイダー:SSOとの連携。

アクセス管理-ユーザを選択します。

f:id:In-houseSE:20210201073911p:plain

・ユーザーを作成をクリック。※ダッシュボードの中央付近となります。

f:id:In-houseSE:20210201073928p:plain

 

ユーザー名を記入して、アクセスの種類を選択します。

 

通常は、マネイジメントコンソールとCLIの2つ使用するため両方にチェックを入れます。

 

コンソールのパスワードは自動生成する初期パスワード、パスワードリセットは初期パスワードでログイン後にユーザで設定するパスワードとなります。

 

自分以外のほかの方のアカウントを作成する場合は、

パスワードリセットを入れておくとよいです。

 

必要な設定をしたら、「次のステップアクセス権限」をクリック。

f:id:In-houseSE:20210201074638p:plain

 

今回はIAMユーザ単体で機能させるため、

既存のポリシーを直接アタッチを選択します。

 

管理者権限を付与するので「Administrator Access」にチェックを入れて次のステップ:タグをクリック。

 

f:id:In-houseSE:20210201075607p:plain

 

チェック時はこちら

f:id:In-houseSE:20210201075744p:plain

 

 

・使用者の分類わけでタグを付与します。

例:キー:Group、値:IT

(今回は種別を分ける必要がないため、未記入のままとします。)

 

f:id:In-houseSE:20210201080008p:plain

 

・ユーザー作成時の設定画面がくるので値を確認後「ユーザーを作成」をクリック。

f:id:In-houseSE:20210201080112p:plain



ユーザー作成が始まるとこちらになります。

他の方のユーザー作成後は、ログイン手順をEメールで送信よりEメールの送信をクリックし相手方に作成したアカウントの初期パスワードの更新などをしてもらいます。

 

f:id:In-houseSE:20210201080201p:plain

業務では同じ部署のグループにまとめて同じポリシーを適用するケースが多いため、

まとめて同じ権限で管理するため、用途に応じたグループを作成します。

例:AWSの管理者は全アクセス権限、アプリ開発する方でDBの管理者はDBのみなど

 

・IAMのダッシュボードより、アクセス管理-グループを選択し新しいグループの作成をクリック。

f:id:In-houseSE:20210201080849p:plain

 

 

今回は管理者用のグループ想定なのでadminとします。

・入力後は次のステップをクリック

※日本語が入力できないため英名で記載になります。

f:id:In-houseSE:20210201081010p:plain

 

・該当するポリシーを選択し次のステップをクリック

f:id:In-houseSE:20210201081206p:plain

 

・確認画面になるため、グループ名と適用するポリシーを確認後グループの作成をクリック

f:id:In-houseSE:20210201081313p:plain

 

 

・グループの作成後、ユーザを所属させるため作成したグループ名をチェックしてグループのアクションよりグループにユーザーを追加を選択します。

f:id:In-houseSE:20210201081517p:plain

 

・先程作成したユーザーを選択しユーザーの追加をクリック

f:id:In-houseSE:20210201081614p:plain

 

通常会社などの組織で使用する場合は、

IAMユーザを作成しそのユーザーを使用してもらうことが推奨となります。

 

今回のテーマは以上です。

SAA学習-Day1対応-part1(多要素認証)

今日のテーマ:Day1対応(多要素認証)

 

タイトルをみてあれ?っとなるかと思いますので、

概要としては、「AWSアカウント作成後の初日に対応しておくことをAWSが推奨する事項」なります。

 

具体的には下記の4つになります。

・多要素認証(MFA)を有効化にする。 → 今日のテーマ

・管理者用IAMユーザーを作る。

AWS CloudTrailを有効化にする。

AWSの請求アラートを有効化にする。

 

用語:

MFA:Multi-Factor Authentication

 

AWSのセキュリティ強化の一環で、

MFAを有効化することとパスワード更新することが推奨とされてます。

 

多要素認証(MFA)を有効化にする。

マネージメントコンソールより「IAM」と入力し検索します。

f:id:In-houseSE:20210129082237p:plain

 

本来はrootアカウントの設定をするのですが、

以前設定していた携帯を交換してしまい解除するにはいったんAWSサポートへお問い合わせして対応が必要です。

 

今回は作成しているAWSユーザのIAMで代用とさせて頂きます。

・ 作成しているユーザをクリックし「認証情報」を選択

f:id:In-houseSE:20210129085050p:plain

 

 

・ 画面のMFAデバイスの割り当てを選択し仮想MFAデバイスを選択している状態で続行

f:id:In-houseSE:20210129085148p:plain

携帯などならQRコードの表示でよいのですが、PCの場合ですとシークレットキーから選択しそちらを活用します。

f:id:In-houseSE:20210129085326p:plain

 

・今回はブラウザでも使用できるChome拡張機能の「Authenticator」で対応。

chrome.google.com

 

・chomeのアイコンより拡張機能を有効化はブラウザの右上のあるこちらから実施。

f:id:In-houseSE:20210129085919p:plain

...うまく画面が取れないのでchomeの拡張機能有効化は割愛させてください。

 

・上のアイコンにもありますが、QRコードっぽいアイコンをクリック

f:id:In-houseSE:20210129090122p:plain

 

・ペンみたいなアイコンをクリック

f:id:In-houseSE:20210129090159p:plain

 

・プラスマークをクリック

f:id:In-houseSE:20210129090243p:plain

・手動入力をクリック

発行者はAWS、シークレットがAWSでMFAを有効化する際のシークレットキーになります。その他の詳細は不要かなと考えてます。

 

・2要素省のワンタイムパスワードがこんな感じで表示されます。

f:id:In-houseSE:20210129090527p:plain

 

AWSのMFA有効化画面にもどって連続する2つのMFAコードを以下に入力で有効化します。

f:id:In-houseSE:20210129090634p:plain

 

・無事登録が成功するとMFAデバイス割り当てに付与されます。

f:id:In-houseSE:20210129090824p:plain

 

cf)ルートアカウントの2要素認証用のデバイスなくした場合

 

Amazonサポートよりからの返答はこちらになります。

 

///////////////////////////////////////
セルフサービスでの解除
///////////////////////////////////////

MFAデバイスはお客様ご自身でも解除できる場合がございますので、

ご参考までに下記ページを記載いたします。
※こちらの方法にて解除いただけない場合もございますので、

その際は大変恐れ入りますが、下記「申請フォームからのご申請」のご対応をお願い申し上げます。

▼MFA デバイスの紛失および故障時の対応:
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_mfa_lost-or-broken.html

▼MFA デバイスが故障または紛失した場合のセルフサービスによるリセットの方法:
https://aws.amazon.com/jp/blogs/news/how-to-reset-mfa-token/

///////////////////////////////////////
MFA解除申請フォームからのご申請
///////////////////////////////////////

▼MFA解除申請フォーム
https://support.aws.amazon.com/#/contacts/aws-mfa-support

上記のページ下部「Support language」を「Japanese」にご選択いただきますと、
担当窓口営業時間内(平日9:00~18:00)に、順次お電話にて対応させていただきます。

 

MFAデバイスのサービスリセットで電話番号認証でエラーでしたので、

うん。MFA解除申請フォームより申請します。

・記載する画面はこちらとなります。

 

f:id:In-houseSE:20210130071817p:plain

 

Day1対応の残りの項目については別記事で掲載していきます。

 

cf)ルートアカウントのMFA認証

 

MFAデバイスをなくしたなどの対応としカスタマーセンターに依頼し再設定を行う対応になります。

※マネージドコンソールへログインした後になります。

 

・MFAが未設定の場合は以下のようにセキュリティアラートが表示されます。

f:id:In-houseSE:20210202073817p:plain

 

 

・ 「MFAを有効」のリンクをクリックし「MFAの有効化」をクリック

f:id:In-houseSE:20210202073945p:plain

 

・仮想MFAデバイスを選択し続行をクリック

f:id:In-houseSE:20210202074027p:plain

 

以降はユーザに割り当てるMFAデバイス認証と同じ対応であれば設定できます。

f:id:In-houseSE:20210202074228p:plain

 

今回のテーマは以上です。

 

SAA学習-AWSでサーバーを構築してみる

今回のテーマ :AWSでサーバを構築する。

AWSの仕組み:
インフラやアプリ開発に必要な機能がオンデマンドでパーツサービスとして提供することができる。
今回はサーバを立てて削除するまでとなります。

・相関変換

種類 AWSサービス
オンプレサーバ EC2
ストレージ S3

・特徴

種類 メリット
オンプレサーバ 時間がかかる。初期費用が高い
EC2 数分で起動。従量課金。

用語:
オンデマンド:いつでもどこでも

・実際の構築EC2構築まで

マネージメントコンソールへログイン
f:id:In-houseSE:20210128081648p:plain

検索欄でEC2と入力しEC2を選択する。
f:id:In-houseSE:20210128081754p:plain

リージョン(AWSサービスを立てる場所)の変更
※画面右上の場所表記
f:id:In-houseSE:20210128082035p:plain

場所の選択します。
f:id:In-houseSE:20210128082129p:plain

画面中央のインスタンスの起動をクリックします。
f:id:In-houseSE:20210128082301p:plain

起動するOSを選択します。
今回はAmazonLinuxの無料枠で起動させます。
f:id:In-houseSE:20210128082400p:plain

起動するインスタンス(サーバー)のCPUとメモリを選択します。
インスタンスのタイプをファミリーとAWSでは定義します。
f:id:In-houseSE:20210128082458p:plain

インスタンスを起動させるNWを選択します。
※カチッとした状態ではなく今回は動かすだけなのでデフォルトで作成します。
f:id:In-houseSE:20210128082710p:plain

サーバに付与するストレージ(ハードディスク)のサイズを指定し作成します。
※画面右側のチェックボックスを有効化しておくとサーバ削除に一緒に削除され残らないため便利です。
f:id:In-houseSE:20210128082848p:plain

タグ(AWSマネージメントコンソールで管理する名称)を設定します。
※設定してなくても後で変更できるため今回は飛ばします。
f:id:In-houseSE:20210128083015p:plain

サーバにアクセス許可をするためファイアウォールルールの設定をします。
f:id:In-houseSE:20210128083204p:plain

確認画面にくるため、起動をクリックします。
f:id:In-houseSE:20210128083355p:plain

サーバにアクセスするためのカギを作成するか既存であるものを設定します。
新規カギを作成時はキーペアのダウンロードをダウンロードしてください。
f:id:In-houseSE:20210128083433p:plain

ダウンロード後インスタンスの作成のボタンが有効化になるので、
そちらより起動をしてください。

作成開始した状態がこちらとなります。
ステータスが確認できないため、右下のインスタンスの表示をクリックしてください。
f:id:In-houseSE:20210128083828p:plain

起動された後の状態はこちらになります。
f:id:In-houseSE:20210128084011p:plain

起動前はこちらになり実際にサーバへ接続する際は、
ターミナルソフトをローカルにインストールして接続が必要になります。
※今回は簡単にTerateamをインストールしている状態で接続してみます。
下記をご参考に頂けると幸いです。
【ゼロからわかる】Teratermのインストールと使い方

・サーバへの接続
接続したいインスタンスを選択し、右ペインの下側にあるパブリックIPv4をアドレスをコピーします。
業務などで使用する場合はNW関連構築してから実装するのですが、
今回は接続するまでなのでパブリックIPアドレスになります。
f:id:In-houseSE:20210128085018p:plain

Terateamを起動するとこのような感じです。
最初に接続するサーバなので鍵認証登録の確認がでるのはいざしたかないので「続行」を押します。
f:id:In-houseSE:20210128085137p:plain

ユーザ認証でちょっと癖がありデフォルトで作成したインスタンスのユーザはec2-userが固定となり、
先程作成した鍵で接続となります。

ユーザ名:ec2-user
RSA/DSA/ECDSSA/ED25519鍵を使う
f:id:In-houseSE:20210128085710p:plain

TereteamでOKを押すとEC2インスタンスにログインするとこちらのようになります。
f:id:In-houseSE:20210128090225p:plain


・サーバの削除
従量課金になるため費用が発生するため接続確認後は削除しておきます。
マネージメントコンソールよりEC2と検索し先程のインスタンスを選択します。
f:id:In-houseSE:20210128090433p:plain

右上のアクションインスタンスの状態をクリックして「インスタンスの終了」を選択します。
f:id:In-houseSE:20210128090537p:plain

確認画面がでるため終了をクリックします。
f:id:In-houseSE:20210128090606p:plain

時間がある程度経過すると終了済みと表記されるので、この状態になると作成したインスタンスが削除されます。
f:id:In-houseSE:20210128090952p:plain

ストレージの削除設定を有効化してないとサーバ消したのになぜ請求されることはよくあるため、
ボリュームを確認してきちんと利用しているストレージがないことを確認しておくことがおすすめです。
何もない状態はこちら
f:id:In-houseSE:20210128091213p:plain

今回は一回AWS上でサーバを作って、接続して、削除まで一連の流れとなります。

今回のテーマは以上です。

SAA学習-AWSアカウント登録

採用したテーマ:AWS(正規名:Amazon Web Service)のAWS認定ソリューションアーキテクチャ

学習元Input:Udemy

 

試験ポイント

・アソシエイトはソリューションを扱うため用語や理論を含め手を動かすことが必要。

 

簡易テスト:

ある企業が、カスタムAMI上のテキストファイルにアクセスキーを格納しようとしてます。その企業はアクセスキーを使用して、AMIから作成されたインスタンスからDynamoDBテーブルにアクセスします。セキュリティチームは、よりセキュアなソリューションを要求してます。

 

セキュリティチームの要求にこたえるソリューションはどれですか?

 

A.アクセスキーをAmazonS3バケットに格納し、起動時にインスタンスからアクセスキーを取得する。

B.インスタンスユーザデータを介してアクセスキーをインスタンスに渡す。

C.プライベートサブネット内で起動されたキーサーバーからアクセスキーを取得する。

D。そのテーブルにアクセスする権限を持つIAMロールを作成し、そのロールを使用してすべてのインスタンスを起動する。

 

答え:D

 

用語類

AMI:Amazonマシンイメージ

カスタム AMI の使用 - AWS OpsWorks

 

アクセスキー:アクセスIDとシークレットアクセスキーで構成されプログラムによるAWSへのリクエストに署名するため使用します。

AWS 認証情報の理解と取得 - AWS 全般のリファレンス

 

インスタンスオブジェクト指向型の言語でですとクラスを自具体化した実態になります。「クラスをnew宣言したもの」AWSの場合ですと仮想サーバとなります。

インスタンスと AMI - Amazon Elastic Compute Cloud

 

DynamoDB:完全マネージド型のNoSQLデータベースになります。

Amazon DynamoDB とは - Amazon DynamoDB

 

AWSのアカウント登録

AWS 無料アカウントを作成しましょう

f:id:In-houseSE:20210125202848p:plain

AWSアカウント登録Top画面

 

 

まずは無料で始めるをクリックします。

 

 

f:id:In-houseSE:20210125203039p:plain

アカウント作成時の画面


続行をおします。

※以降は作成しているので以降は下記の登録があります。

「連絡先情報」:住所などの情報を登録ください。

「支払い情報」:クレジットカードの登録。完全無料枠で試験範囲に構築ができないため、一部有料のサービスが必要となります。

 「本人確認」:携帯電話でも可能なので本人確認通知を受け取れるものを設定してください。

 

アカウント作成時は「ベースライン」で登録をしてください。

 

移行数分的とAWSへの登録ができコンソールへサインインし、登録した認証を通過後晴れてAWSが使用できます。

 

PS:次回以降はこのテーマに沿って講義を受けつつアウトプットしている記事を掲載しようと思います。

 

 

 



 

 

 

 

学習記録ブログ

はじめまして

 

IT業界業界で10年以上業務しており、

今まで客先常駐型のSESで下済みを積んでいきました。

 

ここ数年仕事の内容はよかったのですが、

諸事情で「一体何のために仕事しているんだろう」と思い悩み

身体を壊して倒れました。

倒れている際に強く思ったこととして...。

 

「自分の業務を会社に貢献し、

   新たな発信源になるようなビジネスに関わりたい」

「地に足をつけて仕事をしたい」

「派遣型ビジネスではない仕事がしたい」

 

などなど考えておりました。

 

この際、転職活動するならどういった会社なのだろうという軸に、

客先常駐型でない事業会社に就職できました。

 

話は変わりますが転職活動時にSES事業の会社の営業さんなどからは、

「事業会社では最近の技術が身につかない」などの揶揄をされることが結構あります。

 

ITの技術職で今まで経験してきた限りですが、

技術を身につけるなら手を動かして理解していくしかないのが、

実情ではという仮説を立てて本ブログを開設してみました。

 

主な目的はタイトルに掲載させていただいている通り、

学習記録ブログとなります。

 

コンテンツ開設については初めてなので、

暖かい目で見て頂ければ幸いです。

 

追伸:

過去掲載していたネガティブトークになりそうなコンテンツは削除しました。