UM式 エンジニア勉強会 勉強会ベテラン編
こんにちは國武です。
以前、AWS認定試験についてnoteを公開しまして
note以外にもエンジニア勉強会で、上記認定試験のことやヒトサラのWebデータ分析などに関して発信しております。
エンジニア勉強会では今回含めると4回発表していることになり、誰よりも多いと自負しております・・・笑
この度は、「実際に認定試験の資格保持者がAWSの業務をやったらどんな感じだったのか」をお話したいと思います。
たくさんの方々に見ていただけましたら幸いです！
第13回 UM式 エンジニア勉強会
ログ基盤ダッシュボードのセキュリティ強化
今回は
・ログ基盤ダッシュボードがどんなものなのか
・本回のセキュリティ強化をおこなった結果どうなったのか
を発表していきたいと思います。
ログ基盤とは
ログ基盤ダッシュボードとは、ヒトサラを開発・運用していく中で利用する各種ログ情報を可視化した開発ツールのことを指します。ログ監視や検索がとても簡単にできるため、各種開発作業時や日々のログ監視業務に利用されています。
ログ基盤ダッシュボードはAWSのOpenSearchServiceを利用しておりまして、オープンサーチダッシュボードという機能を用いて各種ログ一覧が表示されている画面を構築しています。
セキュリティ強化について
今回はこのログ基盤ダッシュボードのセキュリティを向上させるというものになります。
調査段階では、ダッシュボードがパブリック上に構築されていたためドメインが公開状態でした。（URLを知っていれば誰でもアクセス可能な状態）
このダッシュボードには既存ログイン認証機能があり、そこに認証は設定されていたためURLにアクセスされても第三者がログインできることはあまりないことですが、やはりそれだけだと心許ない状態でした。
セキュリティ強化のイメージ
既存のログイン認証前後に、もう1段階何かしらの認証情報を追加してログ基盤画面にアクセスできるようにしたいと思います。
調査概要
具体的にどうやってセキュリティを強化するのか。
考えた案は大きく2つあります。
1つ目はCognito(コグニート)というAWSのサービスを利用する方法です。
2つ目は、プロキシーサーバーを経由してログ基盤ダッシュボードにアクセスする方法です。
この2つの案を、実際に実現可能か検証環境で調査。
第1案のお話の前に、まず「Cognito」とは何かということを説明したいと思います。
Cognitoは、Webアプリやスマホのアプリにユーザーのログイン機能やその他諸々のセキュリティ制御機能を簡単に付与可能なAWSのサービスです。
アプリケーションにアクセスする前のセキュリティ対策として設置したり、X（旧Twitter）やfacebook等のソーシャルメディアログイン機能を容易に導入したりすることが可能です。
先ほど具体案として説明した「① Cognitoを導入する案」を実際にやってみたいと思います。
理想としているイメージは、Cognito認証が成功後、既存ログ基盤ダッシュボード認証画面に遷移し、それも認証成功できたら実際にアクセスできる流れです。
CognitoでユーザープールとIDプールを作成し、ユーザー作成後にオープンサーチダッシュボードとAWSコンソール上で連携します。これで実際に繋ぎ合わせができるかどうかを調査しました。
案①の調査結果
導入テストの結果ですが、結論から申し上げますと
・・・できませんでした。
理想とする、「Cognito認証 → オープンサーチのダッシュボード認証」 の流れは実現不可能で、ダッシュボード認証の代わりにCognitoを使ってアクセスすることはできました。
Cognitoの場合、AWSコンソールというAWSの管理画面にアクセス権がないと認証ができないのでログ基盤ダッシュボードよりセキュリティの面は高くなります。
ただ、都度AWSにログインをしなければいけないため容易性は落ちます。
第2案の「プロキシサーバーを経由する」という方法も調査。
プロキシサーバーとは、ウェブサイトにアクセスするときにアクセス機器(パソコンやスマホなど)の代わりにウェブサーバーの間に入り、代理アクセスを実現するサーバーのことです。
プロキシサーバーを実際にテスト導入し、理想イメージがどこまでできるのかを試してみました。
プロキシーサーバーを構築することから開始。
(実際にEC2を利用してサーバーを立てるのは初めての作業でした！！)
実際にインスタンスを作成して、 サーバーを立てて、その際にアクセスキーやセキュリティグループといったセキュリティの設定を行ないました。
次にサーバーの設定です。
サーバーにはnginx(エンジンエックス)をインストールして、httpsの認証の設定を行いました。
サーバーの設定が完了したら、ログ基盤ダッシュボードにアクセスする設定とBasic認証の設定をコンフファイル(サーバーアクセス設定用の設定ファイル)に記載し、動作確認を行います。
案②の調査結果
プロキシサーバーを実際に導入して検証した結果、Basic認証からオープンサーチダッシュボードの認証を経てログ基盤アクセスが無事成功することがわかりました。
懸念としては、Basic認証の設定ファイルを初めて1から書いたため、複雑になってしまったと言うことです・・・。
最終結果
最終的にどういった結果になったかをお伝えしたいと思います。
ログ基盤にアクセスするにはVPNを必須にしました。理由としては、Basic認証が1段階追加もできるため、より高度なセキュリティを実現できるということがわかったからです。
万が一、Basic認証のパスコードがどこかに漏れてしまってもVPNが必須であれば、社員しかアクセスできないという制限が実現可能です。
プロキシサーバーの設置はVPNを必須にすることと、その他ルーティング等々を設定する必要がありました。
そうした構築や設定をしてできたVPN必須の環境下で、「プロキシサーバーにアクセスして、オープンサーチダッシュボードの認証成功後ログ基盤ダッシュボードにアクセス」といった理想の形が実現できました。
最後に私の今回の調査の感想としまして、
日々AWSの記事などからいろんな用語や設定を見ている中で、今まで見ていた用語や設定項目などが実際にたくさん出てきて、「あ！これはこの内容を指していたんだ」と、以前資格試験のために学んでいたことの伏線をたくさん回収できたなと良い経験ができました。
当初はサーバーを構築する予定はありませんでしたが、急遽プロキシサーバー導入の案が出てきた段階でサーバーを構築することになりました。
簡易的ではありますが、実際にサーバーを立てたりネットワーク諸々の設定も体験できたのでとても良い経験になりました。
その反面、ネットワークやサーバーといったインフラ関係の基礎知識がまだまだ貧弱だなと反省点もしました。
そして今後も通常のヒトサラWebの開発・保守業務のみならず、今回のようなクラウド関連作業にも精進していこうと思いましたし、モチベーションアップにつながるとてもいい経験ができました。
最後に
■研究してみてどうでした？
実際にAWSコンソール画面を触れる際、試験勉強で得た座学的な知識が生きる場面が多くあり、作業していて楽しかったですね。
あと、サーバーを立てたことなんて今までやったことなかったため少し緊張しました・・・。
■数々発表してきた中で、どの発表が一番印象深く残っておりますか？
やっぱり今回の内容ですね。
今までは認定の話や技術的なtipsなどの内容がほとんどで、私の業務上での成果発表したことは初めてでした。
自己満足ですけど、とても達成感はありましたね・・・笑
（補足としては、後日勉強会の録画を見直していると、自分の発表がどうにも分かりづらく長すぎるなと・・・
それ故、非常に退屈に感じてしまいました。
もっとプレゼン上手になりたいなと思いましたね。）
■noteを見てくださった方々にお伝えしたいことはありますか？
AWSに知見のあるエンジニアの方で、もし他にセキュリティ強化方法案があれば是非コメントください！！
ご一読くださいましてありがとうございました。