ネットコム主催"オンプレミスサーバ・AWSサイト間VPN構築研修"を受けてみた

本記事は  【Advent Calendar 2024】  18日目の記事です。
🌟🎄  17日目  ▶▶ 本記事 ▶▶  19日目  🎅🎁

はじめに

はじめまして、2024年5月にキャリア入社した竹下です。

キャリアで入社した私ですが、エンジニア歴は2年程度と短く知識も偏っていたため、転職活動では研修が手厚い企業を中心に見ていました。
ネットコムでは研修の受講を推奨する文化があり、ネットコム主催の研修だけでなくNRIグループや外部団体などが主催する様々な研修を受講することができます。

今までいくつか研修を受けてきた中で、今回はネットコムのクラウド部主催の"オンプレミスサーバ・AWSサイト間VPN構築研修"についてご紹介したいと思います！

研修の概要

この研修の目的は、オンプレミス環境に構築したアプリケーションをAWS環境へ移行することを通して、ハードウェアやサーバ、ネットワークについて理解することでした。

大まかに以下の流れで進めていきます。

1. 物理サーバに触れる

2. オンプレミス環境を構築する

3. AWS環境を構築する

4. オンプレミス環境からAWS環境へアプリを移行する

オンプレミスとAWS環境の構成は以下のようになっていて、最終的にはVPN接続を通じてオンプレミスに構築したアプリとDBをAWS環境に移行することを目指します。

各ステップについて、アプリエンジニアがインフラ方面の研修を受けた感想を交えつつ紹介していきます！

物理サーバに触れる

この研修はサーバールームでの開催でした。
最近はAWS環境で動くアプリの開発がほとんどですし、オンプレミスで動かしていたとしても物理サーバで直接作業することはまずないので、ネットコムのサーバールームには初めて入りました。
"目の前のサーバを壊してしまったら何かのシステムが終わるかもしれない"と思うと少し緊張します。笑

物理サーバの理解を深めるため、開発用のサーバを使ってCPUやメモリ、NICなどがどこにあるかを見ていきました。
AWS環境ではCloudWatchなどからCPUやメモリの使用率などを確認することはよくありますが、実態を意識することはあまりありません。
当たり前ですが、CPUやメモリの状況は画面から直ぐアクセスできるけれど、実際は世界のどこかにある物理CPUと物理メモリにアクセスしていると思うと不思議な気持ちになります。

オンプレミス環境を構築する

AWS環境へVPN接続を介してアプリを移行するには、オンプレミス環境にネットワーク環境を構築する必要があります。
今回はCiscoルータを使ってルータのセットアップから進めていきました。
ルータの設定はTera Termを使用してルータにコンソール接続し、設定コマンドを実行して進めていきます。
ルータの設定をしたことが無かったので、馴染みのないコマンドが多かったのですが、
ルーティング設定やIPアドレスの割り当て、NATの設定などなどほとんどの手順でipというコマンドが登場し、かなり多機能なコマンドだなと思いました。

初めての設定で最初は理解が追いつかないまま進めていたのですが、やっていること自体はAWS環境でネットワーク設定をする手順とほぼ同じであることにだんだん気が付きました。
アプリエンジニアとしてはネットワークを構築する機会はほとんど無いので、低い学習コストで直感的にネットワークを構築できるAWSコンソールのありがたみをひしひしと感じます。

ルーティング設定ができたら、物理サーバ上に仮想のDjangoアプリサーバとMySQLサーバを構築していきます。
今回はインフラ周りの知識を学ぶことに重点を置いているため、移行するアプリやDBのソースはすでに作成いただいており、無事アプリを構築するところまで完了できました。

AWS環境を構築する

続いてAWS環境の構築を進めていきます。

改めて、オンプレミス環境とAWS環境は以下の構成です。

1. VPC、仮想プライベートゲートウェイ、カスタマーゲートウェイを作成する

2. 仮想プライベートゲートウェイをVPCにアタッチする

3. 続いて作成した２つのゲートウェイ間でSite-to-Site VPN接続を作成する

4. VPN設定をCiscoルータにインストールしてVPN接続を確立する

ここまでがAWS環境とオンプレミス環境でVPN接続を確立するまでの主な流れです。

今までに2つAWSの認定資格を取得していたので、試験勉強の中でリソースやVPN接続の確立方法は聞いたことがありましたが、実際に構築するのは初めてでした。
「百聞は一見に如かず」とはこのことで、実際にVPN接続を構築していくことで、テキストで何度も説明を読んでもなかなか頭に入ってこなかった各リソースの役割や手順の意味が容易に理解できました。
AWS認定試験などの際にテキストで学ぶことは自己学習として進めやすいですが、今回のように物理サーバやルータの準備がいるようなハンズオンはなかなか自分で進めるのは難しいので、これを機に理解が進められたことはとてもよかったなと思います。

オンプレミス環境からAWS環境へアプリを移行する

最後に、VPN接続されたオンプレミス環境からAWS環境へアプリを移行していきます。

DBサーバはAmazon Data Migration Service(以下DMS)というサービスを使いました。
今回のようなデータベースの移行や、継続的にデータのレプリケーションを実施するような場面で使われるサービスのようです。 aws.amazon.com

DMSの設定をすると、事前に構築しておいたAuroraDBへオンプレミス環境のDBがレプリケーションされました。
実はDMS自体は担当アプリで使っているサービスだったのですが、構築には関わっていなかったため、こういう仕組みになっていたんだなぁと学びになりました。

アプリサーバはAWS Application Migration Service(以下MGN)というサービスを使って移行しました。
オンプレミスからAWS環境だけでなく、AWSの別々のリージョン間での移行もできるサービスのようです。

aws.amazon.com

MGNの設定をし、レプリケーションを開始すればAWS環境でオンプレミス環境のサーバがレプリケーションされたEC2が起動します。
ここまでの設定が正しければ問題なく完了するはずですが、これまでの研修でMGNの手順で何度か失敗することもあったそうで、どきどきしながら完了を待ちました、、。

結果、無事１回でサーバ起動まで完了しました！🎉
約一日かけて構築したサーバやネットワーク環境が無事稼働し、AWS環境へ移行できたので、とても達成感を感じました！！

研修を受けて

今回の研修ではアプリを移行する作業だけでなく、各環境の構築もハンズオンで進められたため、アプリエンジニアとしてはあまり触れることのないハードウェアやネットワークの設定に触れらました。
今後ネットワーク設定などの業務をする機会はあまりないと思いますが、周辺知識として持っておくだけでアプリ設計時や障害時の対応など様々な場面で状況理解の解像度が上がり、より良い設計やスムーズな対応につながるのではないかなと思っています。
今回の研修にとどまらず、今後も様々な研修を受け、業務では得られない知識を身に着けていきたいなと改めて思いました。

なぜPMからの指示はいつも面倒くさいのか

本記事は  【Advent Calendar 2024】  17日目の記事です。
🌟🎄  16日目  ▶▶ 本記事 ▶▶  18日目  🎅🎁

こんにちは。金融ITソリューション事業部の佐藤です。 週末は２歳になった息子と近くの公園に遊びに行くのが習慣になってきました。最近息子は滑り台の楽しさを覚えてしまい、１０回くらい一緒に滑るためとても疲れます。子供との体力の差に愕然としています。

昔は面倒くさいな、と思っていたこと

いま、あるシステムの基盤更改プロジェクトのPMをしています。 このような規模のPMは初めての経験であるため、日々どうしたらよいか悩みながら進めています。

プロジェクトを進めるために度々私からメンバーに向けて指示や依頼をするわけですが、
「自分が言われたら面倒くさいやつやなぁ。」
と思いながらお願いしています。

ということで、自分がプロジェクトのメンバーだった時、PMから言われて面倒だったことを考えてみました。

「スケジュール更新してください」

昔は
「やることやってるし、口頭で報告しているからあとで更新でもいいやん。。。」
と思っていました。

プロジェクト内のタスクとその進捗を管理するためにWBSなどを使いますが、PMとしては最新のステータスになっていることを望みます。 毎日その日の終了時点の状態になっているのが理想ですが、せめて週１回定例の前に更新してよ～と思います。 週１回行っている進捗定例の際にステータスは古いままで口頭で報告を受け、
「WBSは後で更新しておきます」
と言われると、
「いや～どうせ更新するなら定例の前にやっといて」
と思います。またPMから上長向けの報告でもスケジュール表と報告に乖離があると問題視されてしまいます。

「お客様から問合せを受けたので確認お願いします」

昔は
「こっちはやることがあるのにまた急ぎで確認依頼かよ。。。」
と思っていました。

PMとしては自分で即答できないものはメンバーに回答根拠の裏付け調査をしてもらうしかありません。 割り込みタスクは面倒なんだろうなと思いながら、申し訳ない気持ちもありますが、心を鬼にして依頼しています。 出来る限り調査期間の確保や調査の目的、対象の明確化を事前に顧客と調整してからメンバーに依頼することを意識しますので許してください。

「いつまでにできますか？」

PMとしては新しいタスクが発生した時や、タスクが遅延しているときなどは
「いつまでにできますか？」
と確認してしまいがちです。

昔は
「期限提示してくれたら優先度考えて対応順考えられるのになぁ。なるはやでやれってことなんか。。。」
と思っていました。

PMとしては期限のないタスクは放置されることが確実なので、期限を決めたうえで管理したいところです。
タスク発生時には、ある程度の期限感も伝えた上で担当者と会話したほうが良いなと感じました。

まとめ

以上、最近考えていたことでした。
PMの立場としては、顧客の要求には迅速に答えることや、顧客や上長へ根拠をもって進捗状況や課題対応状況を報告することが重要です。 ただ、プロジェクトメンバーとしてはそんなことより自分のタスクを進めることが重要なので、PMからの指示は面倒だなと思いがちなのでしょう。 プロジェクトメンバーを経てPMをやっている自分としては、メンバーの気持ちも理解してプロジェクトを円滑に進めるよう工夫しなければならないですね。

いい歳してまだまだPMとしては道半ば。周りの人に支えられていることに感謝しつつ、精進あるのみです。

最後まで読んでいただきありがとうございました。

請求代行を利用していても大丈夫。AWS Organizationsの始め方！！のWebinarを開催します。

こんにちは、佐々木です。
直前のブログ告知で恐縮なのですが、明日（2024/12/18）の12時にWebinarで登壇します。 テーマはマルチアカウント管理の始め方ということで、AWS Organizationsを導入したいけど様々な制約で困っている人向けです。

解決したい問題

　解決したい問題は、ズバリこれです。
AWSのアカウントが、自社や請求代行、あるいはシステムを構築したシステムインテグレーターなど管理主体がバラバラのケースです。

　これまで、AWS Organizationsに関するセミナーを多数開催してきました。その中で頂いたフィードバックとして多いのが、「うちは請求代行をつかっているから、Organizations使えないのが残念」という言葉です。
　この言葉が結構悲しいので、下記の2つのケースを解決するために、Webinarで解説します。

• AWS Organizationsに移行するのは難しくはない
• 請求代行経由でも、AWS Organizationsを利用できる（ケースもある）

Webinarで話すこと

AWS Organizationsへの移行

　既存でAWSを利用している場合は、かならずどこかに請求アカウントが存在しています。ご利用のアカウント自体が請求アカウントを兼ねている場合もあれば、他のOrganizationsに属していてその請求（マネジメント）アカウントに紐づいている場合もあります。あるいは、AWSアカウントの所有形態として、自社所有・他社所有の2つのパターンがあります。それぞれのケースごとに、どうやって移管すればよいのかを説明します。

すでに請求代行を使っていて、AWS Organizationsを利用できない

　このテーマに興味をもつ方で一番多いのは、既に請求代行を利用していてAWS Organizationsを利用できないといったケースではないでしょうか。実際、私もそういう声を直接聞くことが多いです。これは、ご利用されている請求代行のサービス次第ですが、よくよく調べてみるとAWS Organizationsが利用可能なプランも最近では出てきています。このあたりのお話もする予定です。
※もちろんNRIネットコムのプランは、AWS Organizationsを利用可能です。

cloud.nri-net.com

その他、気になること

　AWS Organizationsに興味がある人は、次のようなことにも疑問を持つのではないでしょうか？下記のようなこともまとめて解説します。

• 既存のシステムに影響ないのか？
• AWSサポートの利用形態（直接AWSサポートを利用できるのか？ エンタープライズサポートのTAMはどうなるのか？）
• AWSアカウントの発行方法は？
• AWS Cost and Usage Reportは利用できるのか？
• 割引オプションの共有はできるのか？
• 使用可能なAWS Organizationsとの連携サービスは？（AWS Control Tower、AWS IAM Identity Center、AWS Firewall Manager、SCPなどなど）

まとめ

　セミナーなので、NRIネットコムのサービスも紹介させていただきます。一方で、たとえNRIネットコムのサービスを利用しなくても、現状で困っている人がいれば解決のヒントになるようなセミナーにしたいと思っています。AWS Organizationsは、非常によいサービスです。長年AWSを使っていて、困っていた部分が段階的に解決していってくれています。ある一定規模以上でAWSを利用する場合は、かならず自社組織用のOrganizationsを作る必要があると思っています。そこの第一歩をお手伝いできれば幸いです。
　お申し込みは、こちらから

nrinetcom.connpass.com

ライブラリを使用したグラフの描画

本記事は  【Advent Calendar 2024】  15日目の記事です。
🌟🎄  14日目  ▶▶ 本記事 ▶▶  16日目  🎅🎁

はじめまして、フロントエンドエンジニアの日高です。

今回はライブラリを使用したグラフの描画についてご紹介します。

はじめに

グラフの描画ができるライブラリはいくつかありますが、今回は実際に私が使用した経験があるChart.jsとWijmoを使ってドーナツ型の円グラフを作成してみようと思います。 任意のHTMLファイルを用意して、それぞれ作成していきましょう。

Chart.js

www.chartjs.org

Wijmo

developer.mescius.jp

Chart.jsでグラフを描画してみよう

1. 導入

CDNから参照することで導入ができます。 下記を<head>内に追加します。

<script src="https://cdn.jsdelivr.net/npm/chart.js"></script>

2. グラフを描画する

まずはグラフを描画する領域として<canvas>を用意します。 id="pieChart"の<canvas>を作成しました。

<div style="width: 500px; margin: auto;">
  <canvas id="pieChart"></canvas>
</div>

用意ができたらチャートを作成していきます。 typeにグラフの種類を、dataにグラフに表示するデータを設定していきます。

<script>
  const pieChart = document.getElementById('pieChart');
  const chartData = [
    {
      label: 'Red',
      data: 600,
      color: '#FF3366'
    },
    {
      label: 'Blue',
      data: 300,
      color: '#3399FF'
    },
    {
      label: 'Yellow',
      data: 100,
      color: '#FFFF99'
    }
  ];

  new Chart(pieChart, {
    type: 'doughnut',
    data: {
      labels: [
        chartData[0].label,
        chartData[1].label,
        chartData[2].label
      ],
      datasets: [{
        data: [
          chartData[0].data,
          chartData[1].data,
          chartData[2].data
        ],
        backgroundColor: [
          chartData[0].color,
          chartData[1].color,
          chartData[2].color
        ]
      }]
    }
  });
</script>

グラフが作成できました。キャプチャは赤い範囲にカーソルを重ねたときの状態です。
赤い部分の情報がツールチップに表示されていますね。

Wijmoでグラフを描画してみよう

1. 導入

導入方法は複数ありますが、一般的なHTML、CSS、Javascriptを使用する環境での導入としては下記2パターンになるかと思います。

• Wijmoの公式サイトからファイルをダウンロードして、任意のフォルダ内に配置する

• CDNから参照する

ファイルをダウンロードする場合は会員登録が必要なため、今回は2つ目のCDNから参照する方法で導入してみます。

まずは下記2つを<head>内に追加します。

<link href="https://cdn.mescius.com/wijmo/5.20241.9/styles/wijmo.min.css" rel="stylesheet"/>
<script src="https://cdn.mescius.com/wijmo/5.20241.9/controls/wijmo.min.js"></script>

次に自身が作成したい機能に合わせてCDNを追加します。 今回は円グラフを作成するため、チャート用のCDNを追加します。

<script src="https://cdn.mescius.com/wijmo/5.20241.9/controls/wijmo.chart.min.js"></script>

2. グラフを描画する

まずはグラフを描画する領域として<div>を用意します。 id="pieChart"の<div>を作成しました。

<div style="width: 500px; margin: auto;">
  <div id="pieChart"></div>
</div>

用意ができたらこちらもチャートを作成していきます。 bindingNameとbindingにグラフに表示するデータを紐づけていき、paletteにそれぞれの色を指定していきます。

<script>
    const chartData = [
    {
      'label': 'Red',
      'data': 600,
      'color': '#FF3366'
    },
    {
      'label': 'Blue',
      'data': 300,
      'color': '#3399FF'
    },
    {
      'label': 'Yellow',
      'data': 100,
      'color': '#FFFF99'
    }
  ];
  const pieChart = new wijmo.chart.FlexPie('#pieChart', {
    bindingName: 'label',
    binding: 'data',
    itemsSource: chartData,
    palette: [
      chartData[0].color,
      chartData[1].color,
      chartData[2].color
    ]
  });
</script>

グラフが作成できました。キャプチャは赤い範囲にカーソルを重ねたときの状態です。
こちらも赤い部分の情報がツールチップに表示されています。 ドーナツ型の円グラフにするためにさらにオプションを追加していきます。

const pieChart = new wijmo.chart.FlexPie('#pieChart', {
  bindingName: 'label',
  binding: 'data',
  itemsSource: chartData,
  palette: [
      chartData[0].color,
      chartData[1].color,
      chartData[2].color
  ],
  startAngle: 90,
  innerRadius: 0.5
});

startAngleで開始角度、innerRadiusで円の内側の半径のサイズを指定します。 これにより作成されたグラフがこちらです。 ドーナツ型の円グラフが作成できましたね。

まとめ

今回はあまりカスタムなどはせずほぼデフォルトの機能のみでグラフを作成しましたが、どちらもツールチップや凡例といったグラフ以外の部分も作成できていました。
私の個人的な印象としては、Chart.jsはベースがある程度用意されているので、気軽に実装することができたように思います。
一方、Wijmoは導入するCDNの選択やオプションの追加といった細かい設定が必要なので実装の難易度は上がりますが、カスタムできる範囲が広いのでより自身の希望に合ったグラフを作成できるように思いました。
他にもいろいろなグラフが作成できるようなので、今後は複雑なグラフの描画にも挑戦してみたいと思います。

re:Invent2024セッション紹介_カリフォルニア州雇用開発局での業務改善

はじめに

こんにちは、クラウド事業推進部の今村です。
re:Invent期間中は毎日平均20キロ弱歩いていたので、タコス・ハンバーガー・ステーキ・ホットドッグ・ピザ・ドーナツの生活でもなんとか太らずに帰国できました。
今回はカリフォルニア州の失業保険、障害保険などの福利厚生プログラムを管理しているカリフォルニア州雇用開発局（以降、EDD（California’s Employment Development Department）） がオンライン失業申請業務を改善した事例の一部をご紹介します。
私は前職で中央省庁システムの業務に従事していたこともあり、アメリカの公共機関がAWSをどのように活用し業務を改善したのか気になったので聴講しました。
今はやりのAIや最新のAWSサービスを利用した構成ではないものの、2020年新型コロナウイルスのパンデミックを経験した公共機関が顧客体験を向上させようと活動した内容はとても聴きごたえがありました。

セッション概要

タイトル：

Driving transformation for California’s workforce

概要：

• EDD ではサービス利用者と従業員の顧客体験を変革するための EDDNext(※1) という取り組みを行い、顧客目線での改善活動を実施している。

• アメリカで最も人口が多いカリフォルニア州では、1/5の家庭で英語以外の言語が利用されている、かつ、Executive Order 内の言語の公平性の基準(※2)に沿うために、EDDNext の取り組みの一つとしてEDD サービスを様々な言語で利用可能にしている。

• 現在では英語のほか、スペイン語・簡体字中国語・繁体字中国語・ベトナム語など、カリフォルニア州で利用されている上位8言語での利用が可能。また、重要なドキュメントも多くの言語に翻訳している。

• 多言語化対応ではAmazon Connect や Amazon Lex を活用し、音声通話・ライブチャット・チャットボット機能を搭載したことで、顧客満足度が2022年から11%アップ

※1 EDDNext

We’re updating online applications, contact centers, the claims process, policies, procedures, and forms, to make your experience easier and faster.

edd.ca.gov

※2 Executive Order 内の言語の公平性の基準

Under the order, the California Health and Human Services Agency and Government Operations Agency will also develop recommendations to improve language and communications access to state government services and programs.

www.gov.ca.gov

www.latimes.com

www.youtube.com

Integrated Contact Center - Amazon Connect

新型コロナウイルスのパンデミック時、それまで58,000件/週程度だった申請件数が1,000,000件/週を超え、オンラインでも電話でも申請できず紙の申請書が大量に届き、とても大変だったそうです。 あの時はどの国も大変だったんですね。。
そんな20年間使い続けたスケール機能すらないシステムを刷新し、2022年からたった2年で顧客満足度を11%アップさせました。
ここでは、刷新したシステムの中でも Amazon Connect を活用した障害保険の問い合わせに関する音声通話フローをご紹介します。

1. ユーザーから電話を受け付け、言語チェックを行います。 言語チェックでは電話番号と言語設定が紐づいていれば別システムと連携しユーザーに適した言語で通話が開始し、言語設定がされていない場合は音声ガイダンスに従って変更可能なようです。
2. Welcome prompt 直後の Rundom number generator では乱数を生成&再生し、それをユーザーに入力させ、スパムコールを除外します。
3. Main menu に移動したタイミングで、「How can I help you 」とユーザーに問いかけます。
4. ユーザーが話した内容は自然言語理解サービスの Amazon Lex を利用することでインプットされます。
5. その後、社会保障番号や生年月日での認証を行い、問い合わせ内容に対する回答を行います。回答に利用される情報はDynamoDBから取得します。
6. 最後にユーザーからの問い合わせを別のサービス（人間）に転送するかどうかを確認して終了となります。
7. 通話記録や、通話までの待ち時間、対話型音声応答で解決できなかった場合の転送先などの情報が CloudWatch を経由した S3 に保存されます。

このシステム運用開始後、電話問い合わせの2/3はオペレーターを介さない対話型音声応答のみで解決できるようになりました。さらに、電話をかけた際に待ち時間が発生したとしても、顧客が都合のいい時間にEDDからかけ直す仕組みをつくったことで、顧客体験のみならず従業員の業務効率も向上させたようです。

Amazon Connect とは

docs.aws.amazon.com

Amazon Lex とは

docs.aws.amazon.com

AWSブログの類似記事

aws.amazon.com

AI を活用した IVR(Interactive Voice Response) システムと IVA(Intelligent Virtual Assistant) 、 Amazon Connect を統合し、企業が顧客体験をさらに向上させる方法についてアーキテクチャ付きで解説しています。

最後に

これまで私は、Amazon Connect も Amazon Lex も名前は知ってるけど、くらいのレベルだったので、どのように利用されているのかデモンストレーション付きで紹介してもらったおかげで使い方のイメージが簡単にわきました。
また、「カリフォルニア州 × AWS」というアメリカ同士の組み合わせではありますが、重要な個人情報を取り扱う公共機関でもAWSが利用され、柔軟なシステム開発が行われていることはとても新鮮でした。

EDD では2022年に顧客調査を行い、顧客体験に重点を置き、かつ社会に最も影響を与えるプロジェクトを優先してプロジェクトを推し進めてきたようです。
2年で一つの公共システムをAWSに完全移行し、今後もさらなる顧客体験の向上のため開発を進めているそうで、便利で優れたシステムを提供したいという熱意がとても伝わりました。

ふと、日本のガバクラってどうなったんだけ？と気になったので調べたところ、こんな記載を見つけました。

ユーザー体験を向上させ、世の中の状況の変化に応じて情報システムを柔軟に変更できるような現代的なアプリケーション開発にとって、柔軟かつ迅速にITインフラを構築することは必須となります。

www.digital.go.jp

日本のガバクラも今後どうユーザー体験を向上させていくのかとても楽しみです。

生成AIにセキュリティ検知の要約をしてもらい、検知に対するアドバイスもしてもらおう！

本記事は  【Advent Calendar 2024】  13日目②の記事です。
🌟🎄  13日目①  ▶▶ 本記事 ▶▶  14日目  🎅🎁

はじめに

こんにちは、大林です。2024年のre:Inventでは、生成AIとセキュリティの統合に関する多くのアップデートが発表されました。本記事では、セキュリティ検知の通知方式を説明の上、生成AIを活用してセキュリティ検知を効率的に管理し、対応する方法をご紹介します。また、セキュリティ検知を通知する意義や生成AIを採用する理由についても解説します。

なぜセキュリティ検知を通知するのか

Amazon GuardDuty（以下、GuardDuty）やAWS Config（以下、Config）を使用することで、システムの開発段階で脆弱性やコンプライアンス違反を早期に検出することが可能です。さらに、これらをAWS Security Hub（以下、Security Hub）に統合することで、各セキュリティ系サービスが検知した内容を一元的に確認できるようになります。そのため、開発段階においてもSecurity Hubの検知内容を随時確認しながら作業を進めることが求められます。
しかし、開発プロセスでは時間的な制約が多く、全ての検知内容を即座に確認するのが難しい場合もあると思います。そこで、重要なセキュリティ検知が発生した際に通知を受け取れる仕組みを導入することで、効率的に対応できるようになります。

通知先を選定する

検知した情報を有効活用するには、ユースケースに適した通知ツールを選定し、効率的な対応につなげる仕組みが必要です。通知ツールをどのように選定するべきなのか説明していきます。
メールは広く普及した通知手段であり、導入コストが低い点がメリットです。Amazon SNSやAmazon SESを活用すれば簡単に実現できます。多くの場合、メールは業務で利用されているので導入に対するハードルが低いことが特徴です。
Slackなどのチャットツールは、検知された内容がチャットツールを通じて即座にチームメンバーに共有されるため、議論を開始したり次のアクションを決定したりするのがスムーズになります。特に複数のチームやプロジェクトが絡む環境では、全員が同時に情報を受け取れることで、効率的な連携が可能になります。
また、BacklogやJiraなどのプロジェクト管理ツールを活用し、セキュリティ検知をチケット化することで、タスクが明確になり、担当者や対応内容が一目で把握できるようになります。また、対応履歴を追跡できるため、どのような対応が行われたかを簡単に確認することが可能です

通知内容に対する通知方法がわからない

アカウント運用は、セキュリティ検知を行うだけでは終わりません。検知内容に基づいて修正を加え、検知傾向を分析し、改善まで実施することが求められます。たとえば、以下のようなセキュリティ検知メールが届いた場合、その内容をすぐに理解し、適切なアクションを取れる人は多くないと思います。
アカウント運用でよく直面する課題の一つに、「セキュリティ検知を通知する仕組みは導入したが、検知内容が十分に理解できず、具体的な改善アクションが実施されない」というものがあります。このような状況を解決するために、AWSの生成AIアプリケーションサービスであるAmazon Bedrock（以下 Bedrock）を活用して、この課題を解決したいと思います。

検知情報：
　検知アカウント：XXXXXXXXXXXX
　リージョン：ap-northeast-2
　プロダクト名：GuardDuty
　重大度：HIGH
　タイトル：The user IAMUser : test is anomalously invoking APIs commonly used in Exfiltration tactics.
　内容：APIs commonly used in Exfiltration tactics were invoked by user IAMUser : test under unusual circumstances. Such activity is not typically seen from this user.
　脅威タイプ：TTPs/Exfiltration/IAMUser-AnomalousBehavior
　オリジナルメッセージ：

{
    "version": "0",
    "id": "test",
    "detail-type": "Security Hub Findings - Imported",
    "source": "aws.securityhub",
    "account": "XXXXXXXXXXXX",
    "time": "2024-XX-XXT18:50:15Z",
    "region": "ap-northeast-1",
    "resources": [
        "arn:aws:securityhub:ap-northeast-1::product/aws/guardduty/arn:aws:guardduty:ap-northeast-1:XXXXXXXXXXXX:detector/test/finding/test"
    ],
    "detail": {
        "findings": [
            {
                "ProductArn": "arn:aws:securityhub:ap-northeast-1::product/aws/guardduty",
                "Types": [
                    "TTPs/Exfiltration/IAMUser-AnomalousBehavior"

Amazon Bedrockを活用したセキュリティ通知

上記の課題を解決する方法の一例として、Bedrockを活用して検知内容に対する具体的な対応策を提案し、その結果を通知に組み込む方法をご紹介します。このアプローチにより、検知通知を受け取った担当者がすぐに改善対応を実施しやすくなります。
このプロセスを通知フローに統合することで、単なる検知情報の報告にとどまらず、具体的なアクション指針を提供できるようになります。運用の流れは以下の通りです。

1. Security HubやGuardDutyで検知された内容をAmazon EventBridgeを経由してLambda関数に送信。

2. Lambda関数が検知データをBedrockに渡し、生成AIによる解析結果を受け取る。

3. Bedrockの解析結果を元に、改善策を含む通知をメールやSlack、Backlogなどのツールに送信。

この仕組みにより、通知内容を具体化し、単なる検知情報の報告にとどまらず、即時対応を促すアクションを提示できます。たとえば、「IAMユーザーの不審なAPI呼び出しが検知された場合、直ちにユーザーのアクセス権限を一時停止し、アクセス履歴を確認する」といった改善案が通知に含まれることで、対応速度と精度を大幅に向上させることが期待できます。
Bedrockを使用した場合の通知は以下です。

生成AIによる要約:
この検知は、IAMユーザー「test」が通常は使用されないAPIを呼び出していることを示しています。これは、データの不正な持ち出し(エクスフィルトレーション)に使用される可能性のある行動パターンです。リモートIPアドレスは日本の東京に位置するXXXXのものであり、通常は見られない異常な行動と判断されています。

生成AIによる対応方法の提案:
ユーザー「test」の行動を調査し、不審な活動がないかを確認することをお勧めします。検知IDは「test」です。また、この検知結果に関する詳細情報は、AWS Security Hubのコンソールで確認できます。

※要約と対応方法の提案は生成AIによって生成されています。必ずしも正しいとは限らないことに注意してください。
　最終的な判断や対応にあたっては、必要に応じて追加の確認や調査を行ってください。

検知情報：
　検知アカウント：XXXXXXXXXXXX
　リージョン：ap-northeast-2
　プロダクト名：GuardDuty
　重大度：HIGH
　タイトル：The user IAMUser : test is anomalously invoking APIs commonly used in Exfiltration tactics.
　内容：APIs commonly used in Exfiltration tactics were invoked by user IAMUser : test under unusual circumstances. Such activity is not typically seen from this user.
　脅威タイプ：TTPs/Exfiltration/IAMUser-AnomalousBehavior
　オリジナルメッセージ：

{
    "version": "0",
    "id": "test",
    "detail-type": "Security Hub Findings - Imported",
    "source": "aws.securityhub",
    "account": "XXXXXXXXXXXX",
    "time": "2024-XX-XXT18:50:15Z",
    "region": "ap-northeast-1",
    "resources": [
        "arn:aws:securityhub:ap-northeast-1::product/aws/guardduty/arn:aws:guardduty:ap-northeast-1:XXXXXXXXXXXX:detector/test/finding/test"
    ],
    "detail": {
        "findings": [
            {
                "ProductArn": "arn:aws:securityhub:ap-northeast-1::product/aws/guardduty",
                "Types": [
                    "TTPs/Exfiltration/IAMUser-AnomalousBehavior"

おわりに

GuardDutyやConfigは、不正なアクティビティやコンプライアンス違反を検知する上で非常に優れたサービスです。しかし、セキュアなAWS環境を維持するためには、これらのサービスによる検知内容を継続的に確認し、適切に対応することが欠かせません。
効率的なアカウント運用を目指すのであれば、生成AIの活用も有効な手段の一つです。AWSでは生成AIに関するアップデートが継続的に行われており、ケースに合わせた最適なモデルを選択することで、より効果的な運用が可能になります。
今後も、セキュリティインシデントの発生を防ぎつつ、運用効率を向上させる方法について情報を発信していきたいと思います。

aws.amazon.com

SIer勤めの僕が考えたエンジニア生存戦略

本記事は  【Advent Calendar 2024】  11日目の記事です。
🌟🎄  10日目  ▶▶ 本記事 ▶▶  12日目  🎅🎁

こんにちは、越川です。昨今の技術革新により、私たちの生活はますます便利になりました。しかし、こうした技術の進歩に伴い、私たちの仕事が将来奪われてしまうのではないか？という話も良く聞くようになりました。

これはエンジニアである私たちにとっても他人事ではなく、エンジニアの仕事も将来的に生成AIなどに代替されるのではないか？という類のコンテンツは増えてきたかと思います。

そこで今回は、SIerの中でエンジニアとして働く私が、今後、エンジニアに求められるものについてまとめてみようと思います。

なぜ今、生存戦略を練る必要があるのか

生成AIの進化は目覚ましく、音楽を即興で作成してくれたり、アプリケーションを自動で作ってくれたりと、今や様々な種類の生成AIがあります。

こうした、生成AIの活用によって、実際の業務スタイルも大きく変わって来たのではないでしょうか？ 分からないことを気軽に聞けるようになったり、成果物の壁打ちができるようになったりと、正に私もこのブログを書く上で生成AIを活用しています。

こうした生成AIの台頭により、単純な仕事やミスが許されないような細かいタスクは、生成AIに代替されていくと考えています。

というのも、そういった作業は、機械の方が得意だからです。私自身、細かい作業が苦手なので、これは常に感じています。人間である以上、ヒューマンエラーは避けられません。

そのため、単純作業や注意が求められる仕事は生成AIに任せ、人間はもっと別の領域にパワーを注ぐべきです。このような状況を踏まえ、今後エンジニアがどのように振る舞うべきかを考える必要があります。

どのようなエンジニアが求められるのか

では、私たち人間はどこに力を注ぐべきでしょうか？それは、現時点の生成AIでは解決できない、より抽象度が高く複雑な仕事です。

特に、様々な要素が絡み合った事象を俯瞰的に捉え、その中で最適解を見いだせる人間が今後、価値を持つと考えています。

実際にプロジェクトを進める上では、様々なステークホルダーや業界事情、各チームメンバーの属性など、複数の事象が絡み合います。それらを総合的に捉え、あらゆる角度から物事を見て最適解を導き出せる人が市場価値的にも高くなっていくのではないでしょうか？

そのためには、技術的なスキル（ハードスキル）はもちろんですが、より抽象的で言語化しにくいスキル（ソフトスキル）の重要性も一層高まっていくと考えています。ソフトスキルについては過去のブログで詳しく述べていますので、ご興味のある方はご覧ください。 tech.nri-net.com

今回は、このような抽象度が高く複雑な仕事をする上で、個人的に重要だと思うマインドセットについて書いてみようと思います。

重要なマインドセット

エンジニアと一括りに言っても様々な種類が存在します。何か特定のエンジニアについて述べるというよりは、個人的にこういうマインドセットがあまねくエンジニアに求められるのかな？という観点で５つほどピックアップしてみました。

1.ラーニングゾーンに身を置く

皆さんはコンフォートゾーンという言葉を聞いたことがありますか？これは、ストレスや不安を感じず、心理的に安全で居心地の良い領域を指します。

コンフォートゾーン以外にもラーニングゾーンとパニックゾーンというものがあります。ラーニングゾーンは未知の領域を指し、パニックゾーンはストレス過多で何も考えられない状態を指します。この3つのゾーンの中で、人が最も成長するのはラーニングゾーンだと言われています。

ラーニングゾーンの特徴は、一定のストレス負荷がかかるということです。ストレスフリーで仕事ができれば望ましいですが、それでは成長が見込めません。コンフォートゾーンは快適ですが成長の機会を逃しやすい、また居心地が良いため漬かりやすい、いわゆるゆでガエル状態になりやすいゾーンです。

成長するためには、未知の領域に踏み込むことが必要不可欠です。不慣れなことをするため一定のストレスがかかりますが、この状態が最も成長する状態です。変化の激しい時代には、自ら積極的にラーニングゾーンに足を踏み入れる勇気が必要です。

補足すると、パニックゾーンに長期間いるのは健全ではありません。職場としては、常にラーニングゾーンになるような環境作りや仕事の振り方をし、何かあればすぐにコンフォートゾーンに戻れる状態を作ることが重要です。

ラーニングゾーンは慣れていくと、やがてコンフォートゾーンになります。そうすると、全体で見た時にコンフォートゾーンの領域が広がっていきます。そうして、またラーニングゾーンの領域を拡大していくんですね。自分の慣れ親しんだ領域を広げつつ、更に未知の領域に入って行くというマインドが重要になります。

2.仕組みを作る側に回る

世の中には大きく分けて、仕組みを作る側と、その仕組みに従う２者に大別されます。希少価値が高いのは明らかに前者です。仕組み化とは標準化を指し、誰がやっても同じ結果になり、同じ品質が担保される必要があります。このような法則性を作ることは抽象度が高く、難易度も高いです。

仕組み化を進めるためには、常にあらゆる事象に対して問題意識を持ち、どうすればもっと良くできるかというマインドを持つことが重要です。つまり、課題を発見する力が求められます。変化の激しい時代において、時流を捉えて適応するためには非常に重要なスキルです。

既存の仕組みに乗るのではなく、その仕組みを改善し、必要に応じて新しい仕組みを作ってより効率化する。このようなマインドセットは今後さらに重要度を増していくと考えています。

3.問題解決を楽しむ

技術は日々進化し、その選択肢は加速度的に増えています。選択肢が増えると、それに伴い問題も増えていきます。

技術的に問題ないと思っていたら、思わぬところでハマったり、逆に技術的には問題なくても社内のセキュリティ事情でNGになったりすることもあります。選択肢が増える世の中では、問題解決の頻度や難易度が上がっていくでしょう。

このような状況で重要なのは、問題解決を楽しむことです。また問題が起きた。。と毎回思っていては、それ以降、太刀打ちできません。むしろ、問題は起きるものだと捉え、ある種のゲーム感覚で処理していく方が、かえって良い答えが出てくるのではないかと思います。

4.ドメイン知識を身に着ける

ドメイン知識とは、特定の領域に関する知識を指します。例えば、建築業界のDXを支援するには、建築業界の知識が不可欠です。

DXのような抽象度の高い仕事が増えている昨今、顧客のドメイン知識を深く理解することが重要です。技術的な観点だけでなく、ビジネスサイドでの最適解を見つけるために、顧客と共にソリューションを考える必要があります。

また、ドメイン知識は社内においても重要です。エンジニアであっても、社内の稟議や手続きについての知識は必要です。

私の会社では、エンジニアがプリセールスを行うことがあります。提案をする際には、与信判断や決裁手続き、契約署名の方法など、様々なプロセスを理解する必要があります。これらの契約の流れを知っているだけでも、社内でも大きなアドバンテージになります。

5.好きこそ物の上手なれ

これはエンジニアに限った話ではないのですが、今後は好きで没頭できるものを見つけることが大事だと思います。好きという感情は、最もローコストで自分を成長させてくれます。

何かをする上で無意識に行動してしまい、誰かにやれと言われなくても、気付いたら調べていた、やってしまった、そんな状態を指します。

よくエンジニアは休日も自己研鑽すべきか？というトピックが議論になりますが、そもそも好きで没頭してしまう人にはこのような概念がありません。誰かにやれと言われなくても、勝手にやってしまうからです。

何時間勉強すればいいのか？どれくらいの量を勉強すればいいのか？といった「〇〇すべき」という概念がないのです。

純粋に考えて、このようなマインドで仕事をしている人と、「いやだなぁ、勉強しないとなぁ」という人では、雲泥の差が開きます。「自分に無理を強いて頑張らないと無理！！」という人は、好きでやっている人には敵いません。

一定期間は無理をして凌ぐことができても、それは時間の問題でいずれ限界が来ます。ですから、自分が楽しい、もしくは得意だと思える分野で勝負することが重要だと思います。

また、情報過多の世の中では、情報を活用できる者とそうでない者で大きな差が開いていくと思います。

私もエンジニアとして毎日情報のアップデートを追っていますが、毎日おびただしい量の情報が発信されています。

それはクラウドプロバイダーのようなベンダーが公開する情報もあれば、個人が発信している情報など様々です。

こういった情報にアンテナを張るという観点でも、やはり好きという感情が重要になってくるのではないでしょうか。

さいごに

生成AIによって仕事が奪われるという脅威論が広まっていますが、個人的にはむしろどんどん活用して自分自身が楽をし、効率的に仕事を進めていけば良いと思っています。

その分、自分にしかできない領域によりパワーを注いでいけば良いのかなと思います。逆に言うと、そういった領域を開拓もしくは自認する努力も今後は必要になってくるかもしれませんね。一人でも多くの方の参考になれば嬉しいです。