当社HumAInにはエンジニア部署にあたる「Technology Division」があります。
そこでは2週間に1回「TDiv Bi-weekly mtg」と呼ばれる受託・社内プロダクト問わず会社全体で進行中のプロジェクトの進捗報告、相談を行っております。
そしてその最後には「Tech Talk」という、現在各自が自己学習していることや、プロジェクトで学んだ技術など様々なトピックを紹介、デモする時間があります。
そこで今回は私が「Tech Talk」で発表してきた内容などを紹介して行こうと思います！
この記事の目次
その1:不正アクセス被害の原因は意外と初歩的かつ人為的な要因が多いかもしれない！？
こちらはセキュリティ意識を高めるいい機会だと思い発表した内容となります。
ちょうどこの時期に世界的有名な超人気ゲーム作品の新作のデータが流出したというニュースが話題になり、調べてみたところ、完全なことは不明ですが、有力な説として
1.フィッシング攻撃を行い偽のメールやウェブサイトを使って、従業員にログイン情報を入力させログイン情報を入手
2.ソーシャルエンジニアリング攻撃として電話やメッセージを通じて、従業員から直接情報を引き出しログイン情報を入手
3.それらで入手したログイン情報を用いて、アクセスを試み、さらには多要素認証疲労攻撃とよばれる、攻撃者がユーザーの認証アプリにプッシュ通知をユーザーが疲れるまで大量に送信し、誤って承認してしまうことを狙う攻撃手法を使って完全に機密情報へアクセスしてしまったという説が有力です。
近年の不正アクセス事件について調べてみたところによると、偽のメールに添付されていた偽のURLにより表れたページで機密情報であるID、パスワードを入力してしまいいとも簡単にID、パスワードが攻撃者の手に渡ってしまうケースが多いようです。
また多要素認証疲労攻撃に関しても、従業員が寝ようとしている午前1時に100回ほど通知を送れば大抵は受け入れる。その従業員が承認すれば、あとはもう思い通りにアクセスできるようになるとのことです。
この発表で学んだこととしては
近年増える一方であるハッキングや不正アクセスですが、そのような文言を聞くとめちゃくちゃ凄腕のハッカーにやられてしまったのだろう、自分とは関係ないと思ってしまいがちですが、実は全くそんなことはないということです。
情報流出は企業や個人にとって多大な損害をもたらすだけでなく、信頼の喪失にも繋がりかねません。私たち一人一人が日々の業務や日常生活の中で、機密情報の取り扱いに対してより一層の注意を払い、セキュリティ意識を高めることが求められています。常に最新のセキュリティ対策を取り入れ、フィッシングやソーシャルエンジニアリングなど人為的問題に対して慎重な行動を心掛けることで、情報の保護と安全な社会の実現に貢献していくべきだと再確認しました。
その2:私は、どうやってとあるプロジェクトのインフラを構築したか!?
こちらは私としては初のAWSの標準のコードでインフラを構築するIaCツールである「CloudFormation」を用いたインフラ構築で、なぜCloudFormationを用いたのかなど導入経緯や実際にCloudFormationのコードをどのようにコーディングして行ったのかを紹介しました。
IaCとは？？
サーバーやネットワークなどのインフラをコードとして管理する手法です。これにより、インフラの構築や設定をテンプレート化し、効率化することができます。
CloudFormationとは？？
AWS標準のIaC機能であり、JSON または YAML形式で記載することできます。
環境構築不要でAWSコンソールですぐに書き始めて実行することも可能です。
Terraformとは？？
HashiCorpが開発したオープンソースのIaCです。Terraformを使うと、コード（HCL: HashiCorp Configuration Language）を使ってクラウドリソースを定義・管理できます。Terraformはクラウドベンダーに依存せず、AWS、Azure、Google Cloud、オンプレミス環境など、さまざまなインフラストラクチャを一元的に管理できるのが特徴です。
しかしTerraformは実行環境を構築する必要があるのではじめは一手間必要になります。
こちらは今後打ち出していく予定である社内製作のプロダクトのプロトタイプを動かすためのインフラを構築していたのですが、ゴーリストグループが明確に分社化したことで、このインフラを構築している途中でAWSアカウントを違うAWSアカウントで構築し直すことを余儀なくされました。
当初私は、あくまでデモンストレーション用のプロトタイプですので、構築の速度重視でIaCツールは用いず、コンソールをポチポチ操作して構築をしていました。
アカウント移管とのことで再度0から別のアカウントでコンソールをクリックして再構築は割に合わないと感じ、ちょうどこの頃にChatGPTが話題になり始めたので、ChatGPTがどれだけ実務で活かせるか気になりましたし、尚且つCloudFormationは私が普段使っているTerraformとは異なりAWS標準機能であるため面倒なセットアップが不要でAWSコンソールのCloudFormationのページでyamlを書くだけで始めることができるのでChatGPTでCloudFormationのコードが書けないかチャレンジしてみることにしました。
この件で学んだこことしては、
実際に作りたいインフラ構成の簡単なメモを箇条書きにしてChatGPTに渡してあげればほぼ求めていたCloudFormationのコードが生成されるのですが、それをそのまま実行とまではいきませんでした。
これには私にも問題があったのです。ChatGPTも完璧ではありませんし、IaCもGUIがない分見落としがちですがコンソールで必須項目となっているところは必ずコードにしなくてはなりません。
必要なものはすべて定義してできるだけ簡潔にChatGPTに問いかければより求めていたIaCコードが生成されることがわかりました！
その3:Kotlin x Springboot x Docker x Kubernetes 入門してみた！
こちらは広く浅くさまざまな技術を触ってみるということでチャレンジしてみた内容となります。
JavaでSpringBootによりMVCモデルを作成した経験は少なからずありますが、それをDocker化してさらにはKubernetesで操る経験はなかったので一度にたくさんのことを学ぼうとチャレンジしてみました。
また、最新技術や今まで触れてこなかった技術はどうしても敬遠しがちですが、まずは何事もhello worldすることから始まり、行く行くはそれの発展だと思っています。
つまりは、どんなに難しそうなことでもわかるところからやっていけば、結局はその応用であとあと余裕になるんじゃないか？と考えて日々「できそうなことから」勉強しております！
以下が開発の内容となります！
まずは、いつも通りspring boot initializerを用いてKotlin用のSpringBoot環境を入手します。
※アプリ名は私の苗字sorazawaとしております。
とりあえずテストの意味も兼ねてControllerクラスを作って
/helloに対してのレスポンスを返すものを作ってみました！
次にちょっとした応用として
レスポンス用のメッセージフィールドだけを持ったdata classを作り
/helloに対してのレスポンスとして先ほど作ったDataClassのオブジェクト
を返すようにcontrollerを作ってみました。
アプリケーションを起動して、
curl localhost:8080/hello
でレスポンスが返ってくるのを確認
続いてテストのコードも書いてみます
・Controllerのテストを書くときはWebMvcTestアノテーションをつけておきます。
そこでMockMvcを使ってテストを書きAutoWiredでDIします。
※・DIとはDependency Injection(依存性の注入)の略で
@AutowiredでDIするとは、オブジェクト指向プログラミングにおいて、
あるクラスに必要となる別のクラスのインスタンスを設定することです！
次にいよいよコンテナ化していきます！
Spring boot のbootBuildImage機能を使います！
Dockerfileを書くことなくImageを作ることが可能です
docker run -p 8080:8080 アプリ名:0.0.1-SNAPSHOT でコンテナを起動できます。
Kubernetesで動かせるように予めDocker Desktopの設定よりKubernetesを有効化しておきます。
Kubernetesで動かすためにデプロイのために、Kubernetesディレクトリ配下にデプロイメントリースのマニュフェストを配置します。
この場合のKubernetesへのデプロイ及び実行のコマンドは次の通りになります
1.kubectl apply -f コマンドで、Kubernetes クラスターにリソースを作成
kubectl apply -f kubernetes
2.kubectl get po でKubernetes クラスター内の Pod の一覧を取得
kubectl get po
3.ローカルマシンの localhost:8080 にアクセスすることで、今回のアプリに直接アクセスできるように、ポートフォワードを行う
kubectl port-forward deployment/sorazawa-app 8080:8080
4.実際にcurlコマンドでレスポンスが返ってくるか見てみましょう！
curl localhost:8080/hello
これでは毎回実行時にポートフォワードが必要になりため、LoadBlancerタイプのマニュアルフェストを書き、あらかじめポートフォワードを指定しておきます！
LoadBalancerタイプのServiceは、外部からのトラフィック アクセスを制御するための基盤を構築を定義することができます！
ロードバランサーリソースを作ったことでそのままリクエスト処理できるようになります。
80番ポートでロードバランサーが受け付けて、アプリケーションのPodの8080番に転送する仕組みになっていおります。
80番ポートで待ち受ける設定ができたことで、ポート番号は指定せずにcurl localhost/helloだけでレスポンスが返ってくるようになりました。
最後に
このような感じで私たちは普段学んだことを定期的に発表しております。
自分で仕事で何となくこなすのと、それをみんなにわかるように説明することは全く異なり、説明できるようになることで初めて理解が進んだと思えます。
更に他のメンバーの発表を聞くことで今まで知らなかった技術を知る事にもなりお互いの発展にとてもいい機会だと思っています。
関連記事
カテゴリー：
