CLI利用時のMFA、スイッチロール設定
CLI利用時のMFA、スイッチロール設定を自分でやったことがなかったため試してみた。
手順1：IAMユーザの作成
ユーザを作成するときは、「MFA」を必須とする。
手順2：スイッチロールの設定
スイッチロールの設定。「MFAが必要」のオプションを忘れずに入れる。今回はスイッチロールは、1つのAWSアカウント内のIAMユーザで行う。よって、スイッチロールのアカウントIDは、設定中のアカウントIDをそのまま入力。
手順3：PCのconfig、credentialsを修正
credentialsに作成したIAMユーザのアクセスキー、シークレットアクセスキーを入力。configには、以下のように記載。
[profile スイッチロール名]
source_profile = IAMユーザ名
mfa_serial = arn:aws:iam::XXXXXXXXXXXXX:mfa/IAMユーザ名
role_arn = arn:aws:iam::XXXXXXXXXXXXX:role/IAMユーザ名
手順4：スイッチロールの「信頼関係の編集」
ここでハマりました。スイッチロールの作成時点では、PrincipalがAWSアカウントのrootユーザになっていた。ここをIAMユーザに変更する必要がある。
以上でCLIからMFA＋スイッチロールできた。
AWS Application Migration Serviceを試してみた
AWSへサーバマイグレーションの予定があったのでCloudEndureについて調査。すると、「AWS Application Migration Service(MGN)」に統合されるとのことだったので、マイグレ時期の点からMGNの調査、検証を行った。
サーバをレプリケーションする仕組みは、CloudEndureを踏襲しているっぽいのでお決まりのBlackbeltで基礎をInput。
https://d1.awsstatic.com/webinars/jp/pdf/services/2020811_AWS_BlackBelt_CloudEndure_Public.pdf
細かい手順は、Amazon Web Services ブログに掲載があったのでそれを参照。
以下はポイント。
・最初にMGNの画面で、「Get started」した方がよい。サーバの追加画面で、sourceのサーバ上で実行すべきコマンドを作ってくれる。
・sourceでAgentインストールの上記コマンドを実行後、MGNの画面から「レプリケーション」を実行。すんなり実行された。実行段階で、Staging用のVPCにEC2が自動で立ち上がる。NameはAWS Application Migration Service Replication Serverである。
・テストの実行は簡単に行えて、「Launch test instances」をクリックするだけ。Target用のVPCにEC2が立ち上がる。スナップショットを利用するらしく、EBSボリューム/スナップショットにMGN関連のものがいくつかできている。
・テスト完了後に、「Mark as "Ready for cutover"」を選択するとテスト用のEC2が削除される。次のチェックを外せば削除されない。Yes, terminate launched instances (recommended).
・テスト時に、EC2のインスタンスのスナップショット、AMIを作成した場合は、「Mark as "Ready for cutover"」を選択しても取得済みのスナップショットとAMIは削除されない。
・Cutover後、「Finalize cutover」を選択するとレプリケーションを管理していた「AWS Application Migration Service Replication Server」のEC2も削除される。
感想だが、V2Cをやりたい案件では簡単にテスト、コンバートが行えて便利なツールだと思いました。インターネットに出れない環境で使えるかは、未確認です。
その他〜〜〜
検証のため、VPC上にネットワークを準備したのですが以下を忘れていてハマった。今後のためにメモ。
Public Subnet上のインスタンスが、インターネットにアクセスするには次のいずれかとなる。
・インスタンスにパブリックなIPを付与する
・Elastic IPを付与する
※Nat Gatewayを利用できない
Private Subnetのインスタンスがインターネットにアクセスするには以下となる。
・Nat Gatewayを利用する
QuickSightのダッシュボードへのアクセス制限とその他
BIツールを勉強中。
●アクセス制限●
Amazon QuickSightへ閲覧者(Reader)のアクセスを以下のようにしたかった。
・Aさんは、全ての事業所の情報を閲覧できる
・Bさんは、事業所Cのみの情報を閲覧できる
調べてみると便利機能を発見。「行レベルセキュリティ(row-level security)」なるものを発見。
簡単に説明すると、「分析をしたいデータセット」とは別で、アクセス制限用のデータセットを作成し、それをもとに「分析したいデータセット」を制限するというもの。今回の場合だと、「Aさんは全部の事業所を見れる、Bさんは事業所Cのみ」を表すCSVファイルをデータセットとして保存し、分析対象のデータセットで読み込めばOK。
Tableauにも同様の言葉はあるので、BI業界では当たり前の機能なんでしょうね。。。
●その他●
特定のユーザまたはグループの閲覧者がQuickSightにログインしたら、あらかじめ特定の部署のみの結果を表示するといった設定をしたい。例えば、Bさんがログインしたら、事業所Cで販売している「Cジュース」のみの売上を表示させる。全ての販売製品の売り上げを見たい場合は、フィルタをいじるといったこと。以下のページを参考にできました。これまた、別のデータセットのファイルを作成して、それを分析対象のデータセットに追加するといった手間が必要でした。
AWS Step FunctionsとAWS EventBridgeのメモ
「システムでのタスク実行を自動化したい、可能であればサーバレスで」といった漠然とした相談から、アーキテクチャを検討。詳細なヒアリングは年明けなので、それに向けて情報を整理。なんとなくだが、AWS Step FunctionsまたはAWS EventBridgeが利用できそうだが、使い分けが不明だったので調べた内容をメモ。（両方とも触ったことがない。触る前の下調べ）
AWS Step Functions：分散アプリケーション・マイクロサービスの全体をオーケストレートする。複数のサービスやタスク実行を制御できるが、ジョブの実行要素を持たない。ワークフロー的なことに利用するには最適。
AWS EventBridge：発生したイベントをトリガーに別のサービスを実行するイベントバスである。これもジョブの実行要素を持たない。Amazon SNSと比較されることから、「発生したイベント」の中身で別のサービスのアクションが異なってくるのではと。
AWS Glueの整理
ゆく年くる年〜2021年の振り返り〜
2021年の振り返り
すでに2022年ですが、2021年の振り返りをします。あくまで個人的なものです。
時系列
1月〜3月：業務でAWSとAzure関連を提案。と、いってもオンプレの情報系システムの基盤をAWSまたはAzureにしましょうというもの。スキルアップのため、AWS Certified Solutions Architect-Professionalを勉強。前年に1度落ちたが、２回目の受験にて合格。しかし、頭の中は「クラウド＝IaaS」みたいな感じ。
4月〜6月：以前から登録していた転職サイトでエージェントより、カジュアル面談の案内をいただく。2年くらい前から面接、面談等をして「不採用」が続いたことから自身のレベルの低さを痛感し、2020年は「クラウド関連」「マネジメント(リーダーとしての振る舞い)」のInputを多めにした。その結果なのか、カジュアル面談では過去に比べると「自分のやりたいこと」「将来像」を自信を持って伝えることができた。その後、複数の企業を紹介いただき内容を精査。業務内容がやりたいことにFitするものを発見。やりたいことは「案件の100%をクラウド関連にする」「技術職として活動する」というものです。4社の面接を受け、そのうち1社に転職することに。
7月：半分ぐらいは有給休暇の消化。個人の権利だが、全部を使うことに負い目を感じて使えず。
8月〜12月：転職。2021年が始まったとき、転職するとは全く想定していなかった。転職先では仕事の大半が「プリセールス的な活動」であるため、「マインドセット」の変革が大変であった。前職ではSIerでプロマネ業務が大半であったため、「お客様に現実を見てもらう」発言をよくしていた。しかし、プリセールスの場合はお客様の購買意欲を高めるため「夢を見ていただく」発言をする必要がある(もちろん、技術的な裏付けはする)。その辺は慣れしかないので、常に自分の発言を振り返るようにしている。また、AWS Certified Security-Specialtyに合格することもできた。
よかったこと
1)人生においてチャレンジできたこと(できていること)
2020年に時代の流行ってだけで、「クラウド関連」のInputを多くしたことで、クラウドにフォーカスした仕事がしたいと思うようになった。その際に「社内異動」か「転職」で悩んだが、会社自体が「クラウド専門の会社」へ転職することで確実にやりたいことに近づく方法をとった。また、転職後は毎日大量にInputできている。転職という一瞬のチャレンジでなく、「クラウド関連の土俵で仕事するチャレンジができている」ことはよかったことである。
課題感とその対応
1)情報のキャッチアップ
上述のとおり、Input多めに活動でき毎日やりがいはある。しかし、スピード感が遅い気もする。技術領域に対して、すぐにカバレッジできるわけもなく、深くできるわけもないことは承知しているが、もっとスピードをあげたい。2022年はInputの時間を多めに確保するよう、会社のスケジュールもBlockしてみよう。
2)プリセールスのスキルアップ(話法)
うまく話せないことが多い。いくつも要因はあるが、主なものは「スキル不足からの不安」だと個人的には思っている。経験則になってしまうが、Inputに合わせてOutputを増やすことで、その不安も解消できる気がする。2022年はとりあえず、OutputとしてこのBlogの投稿数を増やしたい。その日学んだことを個人的なメモ書き程度で、他人にわかりやすく話す練習としてBlogを使っていきたい。
AWS Key Management Service(KMS)の整理
AWS KMSとは、AWS内のサービスで利用可能な暗号化キーを作成・管理・保管するマネージドサービス。
(基本的な用語)
カスタマーマスターキー(CMK)：暗号鍵の一番上
データキー：暗号化に利用。漏れたらまずいので使い捨て。
エンクリプトデーターキー：CMKで暗号化されたデータキー。復号する際に利用。何度も利用。
キーマテリアル：暗号化アリゴリズムで使用されるビット単位のシークレット文字列。CMKのメタデータ（作成日など）を除いた部分。
HSM：暗号以下処理を行う場所。
サーバ側暗号化：ディスク保存時に暗号化し、ダウンロード時に復号化する。
クライアント側暗号化：クライアント側で暗号化し、AWS側にアップロードする。
(カスタマーマスターキーの種類)
カスタマー管理(カスタマーマネージドキー)：キーローテが1年ごと。
AWS管理(AWSマネージドキー)：AWSが作成、管理。キーの名称が「aws」で始まる。キーローテは3年ごと。
AWS所有キー：AWSが所有する。キーローテをユーザで管理することはできない。
ーーーAWS CloudHSMは専用のハードウェア上で暗号化処理を行うーーー
