AWSマネージドなNework Firewallがリリースされたのでプロキシサーバ替わりにしてみる
re:Invent直前、素敵な機能がリリースされたようです。
Network Firewallとは
ネットワークレイヤーでVPC内のリソースを保護できるAWSマネージドなFirewallのようです。 と言ってもよくわからないので実際に作って挙動を見ていきます。
これまで、外部アクセスをフィルタリングする場合はオープンソースのプロキシサーバであるSquidなどを使用してEC2でプロキシサーバを構築していましたが、これを使用することでマネージドな形でURLフィルタリングができます。
今回の構成
ドキュメントのルーティング例にある一番シンプルな構成で作ります。 私の場合はEC2を配置するサブネットを10.0.0.0/24で作成しています。 配置したEC2から、外部通信時にFWを通すようにします。
Simple single zone architecture with an internet gateway - Network Firewall
※東京リージョンにはまだないため、今回はバージニア北部リージョンで試しています。
Network Firewallの作成
VPCのメニューに新しい項目が・・
ファイアウォールを作成していきます。
このような概要説明も画面に表示されていました。
任意の名前を設定し、パブリックサブネットを2つ選択します。（名前がelbとなっていますが通常のパブリックサブネットです）
初回のため空のポリシーを作成し、ファイアウォールを作成します。
作成できたので、実際のルールを適用するためにルールグループを作成します。 ルールグループはステートレスとステートフルの2種類がありますが、今回はステートフルで作成します。
ルールグループは以下の３つから選べます。ここではドメインベースで外部アクセスの拒否を使います。 IPSベースのルールも選べるようで、今後活用できそうですね。
キャパシティは1にするとエラーになるため、10としておきます。作成後にこの値は変更不可のようなので注意です。
アクセス拒否したいドメインを記載し、アクションでDenyにします。 今回はサンプルとして「www.yahoo.co.jp」にしました。
作成を押すとルールグループが追加されます。
ファイアウォールの設定はここまでです。
Route Tableの設定
VPCの通信をファイヤーウォール経由とするため、Route Tableの設定を変更していきます。
具体的には以下赤丸のとおり３か所のルートテーブルを設定しますが、私はInternet GatewayにRoute Tableを設定するという概念が今まで頭になかったのでそこに悩んでしまいました。。
実際に設定していきます。
① Internet Gatewayの Route Table
通常とは異なるルートテーブルを設定するため、新たにルートテーブルを作成します。
作成したルートテーブルを選択し、アクションからEdit edge associationsを選択します。（Internet Gatewayと関連付けるため。私はここで初めてやりました）
Internet Gatewayに関連付けしてSaveします。
関連付けしたルートテーブルを編集し、以下のとおりターゲットをFirewallのエンドポイントに設定します。
※ここもわかりにくいのですが、選択肢にはFirewallという文字はなく、Gateway Load Balancer Endpointから選択します。おそらく裏ではこれが稼働しているためです。エンドポイントの情報は、ファイアウォール画面＞ファイアウォールの詳細タブ＞ファイアウォールエンドポイント から確認できます。
※エンドポイントはサブネット単位のため、マルチAZの場合は複数のルートが必要です。
これで一つ目のルートテーブル設定は完了です。
② Firewall Subnetの Route Table
Firewallを配置したサブネットのルートテーブルです。ここは通常のパブリックサブネット同様、以下のように設定すればOKです。 VPC向けのlocalと、0.0.0.0向けのIGWです。
③ EC2 Subnetの Route Table
最後にEC2を配置するサブネットのルートテーブルです。vpce-**となっているのは、ファイアウォールエンドポイントです。 デフォルトゲートウェイ（0.0.0.0)として、ファイアウォールにルーティングさせます。
以上で3つのルートテーブルの設定は完了です。Internet GatewayのルートテーブルとEC2のルートテーブルそれぞれでFWにルーティングさせて、FWサブネットを経由させる形ですね。
EC2から外部疎通確認
ファイアウォールの準備ができたので、サブネットにEC2を構築して外部疎通してみます。 （EC2構築手順は割愛します。）
まずは拒否されていない「www.google.co.jp」にcurlでアクセスしてみます。
[root@ip-10-0-0-58 ~]# curl -I https://www.google.co.jp/ HTTP/2 200 content-type: text/html; charset=Shift_JIS p3p: CP="This is not a P3P policy! See g.co/p3phelp for more info." date: Wed, 18 Nov 2020 06:08:16 GMT server: gws x-xss-protection: 0 x-frame-options: SAMEORIGIN expires: Wed, 18 Nov 2020 06:08:16 GMT cache-control: private set-cookie: 1P_JAR=2020-11-18-06; expires=Fri, 18-Dec-2020 06:08:16 GMT; path=/; domain=.google.co.jp; Secure set-cookie: NID=204=TrfasTpATfsY4c6PAqxv9izTeDMO-A9qoTOW86D4FrM0F_ChpBcER3tsdYfu7ARzYogEkEYo2MUYw60BbscDozNSizUyjtx4u2bSk6MJ_hefdf9RD_lggp_RLQrUoMUI7eZq-MgRVf7r_OozmjvJLinf7vnehJdBu1ImwwUToiU; expires=Thu, 20-May-2021 06:08:16 GMT; path=/; domain=.google.co.jp; HttpOnly alt-svc: h3-Q050=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-T051=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
エラーなくステータス200で返ってきますね。
次に拒否している「www.yahoo.co.jp」。
[root@ip-10-0-0-58 ~]# curl -I https://www.yahoo.co.jp curl: (28) Operation timed out after 300992 milliseconds with 0 out of 0 bytes received
タイムアウトとなりました！ドメインで拒否できていることがわかりますね。
まとめ、感想
Route Tableで詰まってしまい、思ったより時間がかかりました。
まだ東京リージョンでは未対応のようなので、東京リージョンやCloud Formationが対応したらテンプレートで作成・管理できるようにしたいです。
また、外部からのアクセスも制御できるようなので、これまでSecurity Groupで対応できなかった特定IPやポートのDenyなどもできるかもしれません（試せていません）
まだまだ奥が深そうなサービスなので、また機会があれば触ってみたいと思います。
ChatOpsの第一歩、Slack（Chatbot）経由でLambda関数を実行する
ChatOps＝チャットで運用を行う という解釈のもと、その第一弾として、私もよく利用するSlack経由でLambda関数の実行をしてみたいと思います。 AWSにはChatbotというSlackとAWSを連携する機能があるので、それを利用してまずは単純なLambda関数の実行を実装してみます。
元々は通知機能がメインのChatbotでしたが、最近ではLambdaやEC2の操作も行えるようになっています。
AWSのbuilders.flashにもChatOpsの記事がありましたので参考までに貼っておきます。 aws.amazon.com
Chatbotのセットアップ
Chatbotのページに行き、クライアントを設定します。
ブラウザでSlackにログインしていない場合は以下のようにSign in のページが表示されるので、ログインします。
ログインしている場合は最初から以下のように連携のページが表示されるので許可します。
ワークスペースが追加されるので、Chatbotを使用したいSlackのチャネルを設定します。
今回私はchatbot-lambdaというSlackチャネルでChatbotを利用していきます。
IAMロールはテンプレートから作成し、Lambda実行予定のため「Lambda呼び出しコマンドのアクセス許可」を追加しておきます。
チャネルが設定できました。
Slack側で動作確認してみます。まずは下記をSlack上で実行し、@awsユーザーをinviteします。
/invite @aws
invite後、以下のようにhelpを実行するとChatbotの色々な使い方が表示されます。
@aws help
lambdaのinvoke（呼び出し）もありますね。
ここまででChatbotおよびSlackの準備は完了です。
Lambda関数の作成
今回はChatbotの実行を試すのがメインなので、関数の内容はとてもシンプルなものにしました。
ランタイムはPython3.8です。IAMロールはデフォルトでOK。
関数のコードは以下のとおり。メッセージをreturnするだけです。
def lambda_handler(event, context): return { 'message': 'Hello from Chatbot!' }
Chatbot(Slack)経由でLambda実行
Lambda関数ができたのでSlackから実行してみます。以下の通りメッセージを打ち込みます。初回はリージョン名を入力する必要がありました。
@aws lambda invoke --function-name ChatbotFunction --region ap-northeast-1
実行するかどうか聞かれるのでYesをポチっと押します。
実行されたようです。Lambda関数に書いた「Hello from Chatbot!」もSlack上に表示されています。
ちなみに2回目以降はリージョン指定が不要なことに加え、--function-nameは省略できたので以下でも実行できました。
@aws lambda invoke ChatbotFunction
まとめ
Slackから気軽にLambda実行、良いですね。この他にもChatbotの機能は多くありそうなので、本格的にChatbotを使用した運用も検討できそうです。 Chatbotに強い権限を渡して何でもできてしまうとそれはそれでセキュリティ的な問題にもなりそうなので、どこまでやるかは要検討ですね。
もうちょっと実際の運用で使えそうなChatbotのネタが無いか考えてみます。
EventBridgeのアーカイブ＆リプレイ機能を使用してイベントを再現してみる
EventBridgeの検証にとても役立ちそうな機能がリリースされていました。
EventBridgeとは
AWS内で発生したイベントやサードパーティ（Zendesk、Datadog、Pagerdutyなど）のイベントをトリガーにLambda関数やSNSを実行できる機能です。 同様の機能としてCloudWatch Eventsがありますが、EventBridgeはCloudWatch Eventsの上位互換的な機能となります。
よくある質問より
Q: Amazon EventBridge は CloudWatch Events とどのように関連していますか? Amazon EventBridge は、CloudWatch Events をベースに構築された、CloudWatch Events を拡張するサービスです。
今回のアップデートについて
一度発生したイベントソースを、アーカイブして再現できることができるようになりました。
例えばCloudTrailやS3へのオブジェクトUPなど、特定のイベントを契機にターゲットでLambdaを実行していた場合、Lambdaの動作テストを行うために、再度イベントそのもの（CloudTrail（＝特定のAPI実行）やオブジェクト再UP）を実行しなければならない場合がありました。今回のアップデートで、そういったイベントの再現を行わずに、ターゲットの検証が実行できるようになりました。
特にセキュリティインシデントをイベントトリガーとしている場合は、中々そのイベントを再現するのは難しい場合もあるかと思います。
試してみる
今回は再現のしやすさから、イベントにGuardDutyのサンプルイベント、ターゲットにSNS＋Chatbot通知という設定で試していきます。（※今回はChatbotの通知設定部分は割愛します。）
EventBridgeから以下のパターンを定義してルールを作成します。これでGuradDutyで検知した内容をターゲットに渡すことができます。
ターゲットにはChatbotを設定したSNSトピックを設定します。
その他は基本デフォルトでOKです。この２つを設定して作成します。
ルールができたので、次にアーカイブを作成していきます。左側のメニューからアーカイブを選択すればOKです。
任意の名前を入力し、ソースには今回作成したルールが所属するデフォルトのイベントバス「default」を選択します。
イベントのフィルタでは、すべてのイベントを対象としても良いのですが、今回はGuradDutyの検証のため、ルール作成時と同様のフィルタパターンを設定します。
アーカイブができました。
アーカイブの準備ができたので初回のGuradDutyのサンプルイベントを作成してみます。
GuardDuty＞設定＞結果のサンプルから生成できます。ポチっと。
しばらくするとSlackに以下のようにたくさんメッセージが飛んできます。
これらのイベントをEventBridge経由で再現してみます。EventBridgeのアーカイブから新しい再生を開始を選択します。
作成しておいたアーカイブとルールを選択し、発生した時刻が含まれるよう開始、終了時刻を選択します。
再生を開始をクリックするとイベントが再生され、しばらくすると以下の通りイベントが再生済みとなります。
再びSlack側を見てみると、以下のように再度新しい通知が行われていました。
ということで、GuradDutyのサンプルイベントの再作成なしで、通知のみの検証を行うことができました。
感想・まとめ
ターゲットの設定でインプットトランスフォーマーを使用した通知内容の調整や、Lambdaの実行を検証したい場合はイベントを意図的に複数回発生させていたことがあったので、そういった検証時に役立ちそうな機能です。
ただ、現状は時間指定での再現のようなので、発生したイベントが一覧で出てきて、特定のイベントを選んで再生。とできるとさらに良いなと思いました。特にGuardDutyのサンプルイベントは数が多すぎるところもあるので・・。今後に期待です。
CloudWatch AlarmsとOpsCenterの連携機能が出たのでインシデント管理が捗りそう
なにやら良さそうな記事が・・
CloudWatch Alarmsで検知したアラームを、インシデント管理のOpsCenterに自動連携してくれるようです。 これでAWS上でアラームをインシデントとして一元管理できるかも？
実際に動かしてみたいと思います。
CloudWatch Alarmsとは
EC2のCPU使用率やClodWatch Logsのログフィルターなど各種メトリクスを、アラームとしてSNSなどで通知できる機能です。
OpsCenterとは
Systems Managerの一機能で、運用担当の運用作業項目 (OpsItems＝障害やインシデント)を管理できる機能です。
今回のアップデート
CloudWatchアラームを作成するときに、ポチっとOpsCenterの設定を有効にするだけで、自動的にアラームをOpsCenterに登録してくれるようになりました。良いですね。
試してみる
実際にアラームを作成してみます。今回はEC2のCPU使用率に対してアラームを設定します。
今回は意図的にアラームを発生させるため、CPU使用率100%以下で検知するよう設定します。
アクションの設定にすすむと、「Systems Manager OpsCenter アクション」が追加されてました。 有効にしてみます。
重要度とカテゴリを入力できました。イイ！
その他は名前など任意で入力してアラームを作成します。
作成後、しばらくすると以下のようにアラームが発動します。
これでOpsItemが作成されたはずなので、Systems ManagerのOpsCenterに遷移して状況を見てみます。 1件のOpsItemが出ていました。想定通りですね。
IDをクリックして詳細を見てみます。 先ほど設定した重要度やカテゴリー、関連リソース（今回はEC2インスタンスとCloudWatch アラーム）が表示されています。
その下には、OpsItemに関するAutomationの実行履歴とランブックが一覧で表示されて、実行できるようになっています。 運用作業や障害対応用のランブックを用意しておけば、誰でも簡単に一次対応（ランブック実行）ができそうですね。
最下部には情報管理に役立ちそうな各種データ登録の機能がありました。 件数集計や類似アイテムの検索に役立ちそうです。
情報をひととおり見たので、ステータスを解決済みにしておきます。
完了！
感想・まとめ
うまく活用することで、AWS上でインシデント管理ができそうですね！
個人的には、CloudWatch Alarmだけではなく、CloudWatch EventsでGuardDuty等の検知も行っているので、そういった情報もOpsItemに登録してAlarm以外のイベントも一元管理するとすごーく良い感じになりそうだなと思いました。
※CloudWatch EventsでもターゲットにSSM OpsItemを指定することで簡単に登録できそうです。
機会があれば何かのプロジェクトで提案したいと思います。
AWS Security JAM 2020 に参加してきた
AWS Security Roadshow内で開催されたAWS Security JAMに参加してきたのでそのレポートです。課題の詳細は記載できないので、概要と感想を書いておきます。
AWS Security Roadshow Japan | AWS
AWS Security JAMとは
以下公式の申込ページにあった記載内容です。
AWS Security JAM は、権限管理、自動化、インシデントレスポンスなどに関連するサービスを利用して、参加者が各課題ごとに AWS 環境を適切に修正するゲーミング形式のイベントです。 参加者はオンライン上で提示されたセキュリティ上の課題に対して、実際の AWS マネジメントコンソールを利用し、ご自身の知識、経験を活用し、必要に応じて学習をしながら課題解決に取り組みます。
実際のマネコンに入って調査、修正を行うので、実運用に近い形式で学習することができます。
実施概要
今回はオンライン開催ということもあり、チーム戦ではなく個人戦でした。2019年はチーム戦だったようですね。
ということで一人でモクモクやっておりました。
セキュリティインシデントが発生しているいくつかのAWSアカウント、システムがあって、示されたセキュリティ要件を満たすように修正していく形式でした。 解決数に応じてスコアがもらえ、参加者の順位がダッシュボードに表示されます。
以下は問題の選択画面です。世界各地でインシデント起きているから解決してクレヨ！と言った感じですね。 問題にEasyやHardと言ったレベルがあるので好きなものを選んで順に解いていきます。
出題範囲
ここは問題の詳細を説明できませんのでざっくりと。 幅広く色々なサービスから出題されます。
大事なIAMから、サーバーレス、ネットワーク系、SecurityGroupやWAFなどのセキュリティサービスなど。課題によって使用するサービスは様々でした。 具体的な設定内容がわからないと解けないので、サービス基礎知識だけでなく実践力も必要でした。
今後参加を検討する方へ
是非参加してみてください！
初心者の方は「難しそう・・」と思うかもしれませんが、課題にはわからない人向けのヒント（スコア減点あり）があったり、AWSの人にも質問ができますので、是非チャレンジだと思って参加してみると良いと思います。実力つきます。
まとめ、感想
とても楽しかったです！新しい知識も色々とつきました。 私はAWS Gamedayにも参加したことがあるのですが、それよりもより私の実業務に近いところだったのがとても良かったです。
ちなみに私の最終順位はTop11（全70人くらい？）でした。序盤の課題で詰まり時間をかけてしまったのが反省点です。
是非日本でもたくさん開催されると良いなと思います。開催していただいたAWSさんありがとうございました。
Oracle CloudでRACデータベースを作成してみる
今回はAWSではなく、Oracle Cloudの記事となります。
ちなみに私はこの記事でOracle Cloudデビューとなります。基礎的な内容かつ、理解が不足している部分があるかもしれませんがご容赦ください。
オンプレミス環境でOracle Real Application Clusters(Oracle RAC)の構築経験があるのですが、 設定内容が複雑であり、インストール時間もかかるので、データセンター内でヒーヒー言いながら構築した思い出があります。
今回はそのRAC構成のデータベースをOracle Cloudではどれだけ簡単に作れるのか？という観点で実際に作っていきたいと思います。 とりあえずRACを作ってみたいという方の参考になれば幸いです。
Oracle Cloud アカウントの作成
本記事ではデータベースを作るところを書きたいのでアカウント作成部分は割愛します。 他のクラウドと同様、メールアドレスやクレジットカード情報を登録することでアカウントの作成ができます。 Oracle Cloud Free Tierという無料枠があるので、今回はその枠を使用して作成していきます。
仮想クラウド・ネットワーク（VCN）の作成
データベースを所属するネットワークを事前に作成します。 VCNと言われ、AWSだとVPC的なやつですね。 左側のメニューから「ネットワーキング＞仮想クラウドネットワーク」を選択します。 選択後、VCNの作成をクリックします。
名前に「OracleNetwork」、CIDRに「10.0.0.0/16」を入力して作成します。
VCN内にサブネットを作成していきます。
名前に「OracleSubnet」、CIDRに「10.0.0.0/24」を入力して作成します。 今回はインターネット経由で接続確認を行う予定のため、パブリック・サブネットで作成します。 実際の本番環境ではプライベート状態で作ることが多いと思います。今回は検証用途ということでご認識ください。
インターネットから疎通を行うため、インターネットゲートウェイを作成し、ルートテーブルを変更しておきます。
作成後↓
先ほどのサブネットに指定したルートテーブルで、宛先0.0.0.0/0、ターゲットInternetGatewayを設定しておきます。
以上でVCNの準備は完了です。
SSHキーペアの作成
データベースインスタンスに接続する際に必要なため作成しておきます。 OCI標準のシェル機能であるCloud Shellで作成していきます。 右上のCloud Shellのマークをクリックすることで下部にターミナルが出てきます。
ターミナル上で下記コマンドを実行します。 Oracle公式ドキュメントのとおりです。
$ ssh-keygen
保存先とパスフレーズを聞かれますので任意で入力します。 今回は全てデフォルトでEnterを押下します。（パスフレーズなし）
実行後、.sshフォルダに公開鍵と秘密鍵が作成されていることを確認します。
$ ls -l ~/.ssh/ total 8 -rw-------. 1 xxxx oci 1679 Oct 12 02:23 id_rsa -rw-r--r--. 1 xxxx oci 401 Oct 12 02:23 id_rsa.pub
データベースの作成
準備ができたのでデータベースを作成していきます。 Oracle CloudにはOracle Autonomous Databaseという良い感じで自動管理してくれるデータベースがあるのですが、 今回はよりオンプレミスに近いRACデータベースを作ってみるという目的で、仮想マシン型のデータベースを作成していきます。
「データベース＞ベア・メタル、VMおよびExadata」を選択します。
DBシステムの作成をクリック
必要情報を入れていきます。
- シェイプ（スペック）はデフォルトから1段階小さいStandard2.2
- 冗長構成（2ノード）で作成したかったが、無料枠ではコア数に制限があるようなのでここではノード数1とする（残念）。
- その他デフォルト
- ネットワークはあらかじめ準備していたVCNとサブネットを指定
- ホスト名接頭辞には任意の名前を入力。今回は「orcl202010」
- 管理ユーザーsysのパスワードを入力。複雑要件が高いです。
「パスワードは9文字から30文字とし、大文字、小文字、特殊文字および数字をそれぞれ2つ以上含める必要があります。特殊文字は_、#または-のいずれかです。」
- その他デフォルト
以上、これで「DBシステムの作成」をクリックします。
作成完了までしばらく時間がかかります。 「プロビジョニング中」になっていることを確認し待機・・
しばらくすると使用可能状態となります。 （私は使用可能になるまで1時間ほどかかりました。普通なのでしょうか）
SSH接続からのSQL接続
Cloud Shell経由で接続してみます。パブリックサブネットに作成したので、ノードにはパブリックIPが付与されています。 先ほどの使用可能状態が見えた画面からDBシステム名をクリックし、左下の「ノード」をクリックしてIPアドレス情報を確認します。
$ ssh -i id_rsa opc@168.138.193.64 The authenticity of host '168.138.193.64 (168.138.193.64)' can't be established. ECDSA key fingerprint is SHA256:xxxxxxxxxxxxxxxxxx ECDSA key fingerprint is MD5:xxxxxxxxxxxxxxxxxxxxxx Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '168.138.193.64' (ECDSA) to the list of known hosts. [opc@orcl202010 ~]$
接続できました。ルートユーザーにもなれます。 oracleユーザーに切り替え、sqlplusで接続してみます。
$ sudo su - Last login: Mon Oct 12 15:20:34 JST 2020 [root@orcl202010 ~]# su - oracle Last login: Mon Oct 12 15:20:34 JST 2020 [oracle@orcl202010 ~]$ sqlplus / as sysdba SQL*Plus: Release 19.0.0.0.0 - Production on Mon Oct 12 15:22:56 2020 Version 19.8.0.0.0 Copyright (c) 1982, 2020, Oracle. All rights reserved. Connected to: Oracle Database 19c EE Extreme Perf Release 19.0.0.0.0 - Production Version 19.8.0.0.0
接続できました！
RAC管理で使用するcrsctlコマンドで状況の確認も可能です。
$ /u01/app/19.0.0.0/grid/bin/crsctl stat res -t -------------------------------------------------------------------------------- Name Target State Server State details -------------------------------------------------------------------------------- Local Resources -------------------------------------------------------------------------------- ora.DATA.COMMONSTORE.advm ONLINE ONLINE orcl202010 STABLE ora.LISTENER.lsnr ONLINE ONLINE orcl202010 STABLE ora.chad ONLINE ONLINE orcl202010 STABLE ora.data.commonstore.acfs ONLINE ONLINE orcl202010 mounted on /opt/orac le/dcs/commonstore,S TABLE ora.net1.network ONLINE ONLINE orcl202010 STABLE ora.ons ONLINE ONLINE orcl202010 STABLE ora.proxy_advm ONLINE ONLINE orcl202010 STABLE -------------------------------------------------------------------------------- Cluster Resources -------------------------------------------------------------------------------- ora.ASMNET1LSNR_ASM.lsnr(ora.asmgroup) 1 ONLINE ONLINE orcl202010 STABLE ora.DATA.dg(ora.asmgroup) 1 ONLINE ONLINE orcl202010 STABLE ora.LISTENER_SCAN1.lsnr 1 OFFLINE OFFLINE STABLE ora.RECO.dg(ora.asmgroup) 1 ONLINE ONLINE orcl202010 STABLE ora.asm(ora.asmgroup) 1 ONLINE ONLINE orcl202010 Started,STABLE ora.asmnet1.asmnetwork(ora.asmgroup) 1 ONLINE ONLINE orcl202010 STABLE ora.cvu 1 ONLINE ONLINE orcl202010 STABLE ora.db1012_nrt1hk.db 1 ONLINE ONLINE orcl202010 Open,HOME=/u01/app/o racle/product/19.0.0 .0/dbhome_1,STABLE ora.orcl202010.vip 1 ONLINE ONLINE orcl202010 STABLE ora.qosmserver 1 ONLINE ONLINE orcl202010 STABLE ora.scan1.vip 1 OFFLINE OFFLINE STABLE --------------------------------------------------------------------------------
AWSのRDSとは違い、OSにログイン出来るのはちょっと不思議な感じがしますね。 （私がAWSに慣れているだけですが）
外部からSQL接続
せっかくなのでローカルPCのSQL Developerからも接続してみます。
DBインスタンスの1521ポートへ接続許可するため、作成したサブネットのセキュリティ・リストに以下のルールを追加しておきます。ソースはDBへ接続するクライアントのIPアドレスです。
ネットワーキング＞仮想クラウド・ネットワーク＞[作成したネットワーク名]>[作成したサブネット名] の順でクリックするとセキュリティ・リストの画面へ遷移できます。
次に接続情報を確認します。データベースの詳細からDB接続をクリックします。
簡易接続の情報をコピーしておきます。
以下のような情報が取れるのでメモしておきます。
orcl202010.oraclesubnet.oraclenetwork.oraclevcn.com:1521/DB1012_nrt1hk.oraclesubnet.oraclenetwork.oraclevcn.com
では接続です。 ローカルPCにインストールしたSQL Developerから接続します。
以下の通り接続情報を入力し、接続します。
- ユーザー名：system
- パスワード：作成時に設定したパスワード
- ホスト名：SSH接続で使用したパブリックIP
- ポート：1521
- サービス名：メモしておいた接続情報の「/」の後部分（今回ではDB1012_nrt1hk.oraclesubnet.oraclenetwork.oraclevcn.com）
接続が完了すると、以下のようにデフォルトで存在するテーブルの情報が表示されます。
接続確認は以上です。
まとめ
ネットワーク（VCN)の作成からやったことを考えると、それなりに時間がかかりましたね。「プロビジョニング中」で1時間待たされるのも意外でした。
ただやはりオンプレミスでOracleRACを作成する場合に比べると格段に速く作成できますので、Oracle RACの動きを見たい場合や、開発環境用途としては良いなと思いました。
今回の手順ではパブリック公開であったりセキュリティ・リストの設定が一部緩い部分もあったので、本番利用の際はここらへんもきちんと設計したいですね。
ではでは～
SecurityHubのレベル別通知が飛んでこなくなった
SecurityHub、使ってますか？細かい内容なのですが、SecurityHubの通知部分のパラメータが変更されていたのでその情報共有です。
Security Hubとは？
Security Hubは、AWSアカウント内のセキュリティ状況やコンプライアンスの準拠状況を1ヵ所で確認できるサービスです。 GuardDutyやMacieなど他のセキュリティサービスで検知した情報もSecurity Hub上で確認ができます。 使ったことのない方は是非一度有効にして確認してみてください。
Security Hubの通知について
Security Hubを有効にすることで画面上で状況は確認できるのですが、セキュリティイベントが発生した場合の検知は別途設定する必要があります。 私は以前Security-JAWSで以下のようなお話をしていました。 「Security Hubの通知を全て行うとたくさん飛んでしまうのでフィルタを検討しましょう」
その中で、レベルがHIGHとMEDIUMのみ通知する設定例を紹介していました。
※CloudWatch Events または EventBridgeの設定です。
とある新しいAWSアカウントでこの通知を検証していたところ、この設定では通知が飛んでこないことが判明しました。
サポートに確認したところ、 AWSのフォーラムで案内があったとのことでした。
通知設定の変更内容
今現在HIGHとMEDIUMのみ通知を行う場合は以下の通り記載を変更する必要があります。
変更前（古い内容）
{ "source": [ "aws.securityhub" ], "detail-type": [ "Security Hub Findings - Imported" ], "detail": { "findings": { "ProductFields": { "aws/securityhub/SeverityLabel": [ "HIGH", "MEDIUM" ] } } } }
変更後（新しい内容）
{ "source": [ "aws.securityhub" ], "detail-type": [ "Security Hub Findings - Imported" ], "detail": { "findings": { "Severity": { "Label": [ "HIGH", "MEDIUM" ] } } } }
「ProductFields.aws/securityhub/SeverityLabel」にあった項目が、「Severity.Label」に移ったようです。
登壇資料も更新いたしました。
こっちはダメよ！
こっちで！
もし私の資料を参考に通知設定をされている方がいましたら、更新よろしくお願いしますm(__)m
下記の記事にも同様の記載があり、まだ古い状態ですので近いうちに更新予定です。
ちなみに、上記HIGHとMEDIUMの設定はあくまで例なので、通知の状況や要件に合わせて設定はカスタマイズするようお願いします。
今後の変更に気付くには
現状はAWSのフォーラムを定期的に確認していくしか方法が無いようです。 メール通知は無いとのこと。ちょっと設定がマニアックで影響のあるユーザーが少ないかもしれないですね。
フォーラムのRSSがあるのでそこを登録して見るようにしたいと思います。
こういった細かいところも気を付けないとなーと反省した出来事でした。
