セキュリティ基準に違反する設定を簡単に修復
「AWS での自動化されたセキュリティ対応」を試してみる
駒原 雄祐
皆さん、こんにちは！ソリューションアーキテクトの駒原雄祐です。
様々なユースケースに対応するソリューションを AWS 上で簡単に構築できる「AWS ソリューションライブラリ」、皆さんはご存知でしょうか ? builders.flash では、紹介記事 も徐々に充実してきました。今回は、AWS 環境のセキュリティ統制に役立つ、「AWS での自動化されたセキュリティ対応」というソリューションをご紹介します。
AWS を利用していて、「アカウント内のリソースのセキュリティが保たれているか不安、Amazon GuardDuty は有効化しているけれど有効化したきりで何をしたらよいかわからない」といったお悩みを抱えていないでしょうか ? このソリューションを使うことで、AWS 環境下で、準拠すべきセキュリティ基準に違反するリソースを検出し、手動もしくは自動でその修復を行うことができます。「検出」だけでなく「修復」までをカバーしているのがこのソリューションの大きなポイントです。
それでは、実際の構築方法や使い方を見ていきましょう。
ご注意
本記事で紹介する AWS サービスを起動する際には、料金がかかります。builders.flash メールメンバー特典の、クラウドレシピ向けクレジットコードプレゼントの入手をお勧めします。
この記事のデモを無料でお試しいただけます »
毎月提供されるデベロッパー向けアップデート情報とともに、クレジットコードを受け取ることができます。
AWS Security Hub とは ?
ソリューションの詳細に入る前に、このソリューションの中核となる、AWS Security Hub を紹介します。Security Hub は、AWS 環境における様々なセキュリティイベントを集約し、一元的な管理・可視化の機能を提供するサービスです。
AWS では、広範なセキュリティをサポートするため、多くのサービスを提供しています。また、クラウド活用が進む中で対象となる環境も単一のAWS アカウントやリージョンで完結せず、複数のアカウントやリージョンにまたがるケースも増えています。これらの幅広い環境で様々なセキュリティサービスが動作している中、個々のアカウント、個々のサービスを開いて状況を確認するのは効率的とは言えません。
Security Hub を活用することでこれらの情報を一元的に集約、管理し、網羅性の高い可視化や、素早い異常検知、対応に役立てることができます。
また、Security Hub の提供する基本的な機能として、事前定義されたセキュリティ基準への準拠状況の可視化があります。
Security Hub がサポートするセキュリティ基準は、執筆時点で以下の 3 つがあります。
AWS 基礎セキュリティのベストプラクティス
CIS AWS Foundations Benchmark
PCI DSS
「AWS 基礎セキュリティのベストプラクティス」に含まれる項目をいくつか抜粋すると、例えば以下のようなものがあります。
S3 ブロックパブリックアクセス設定は、バケットレベルで有効になっている必要があります
VPC のデフォルトのセキュリティグループはインバウンドトラフィックとアウトバウンドトラフィックを許可しない必要があります
EBS のデフォルト暗号化を有効にする必要があります
このように、このセキュリティ基準では、AWS 環境を安全に運用するためのベストプラクティスが定義されており、セキュリティレベルを高めるために実践すべきことの指針とすることができます。
Security Hub では、集約された各種情報からこれらの項目に対する準拠・非準拠をチェックし、どれぐらい準拠できているかをダッシュボードで可視化することができます。
クリックすると拡大します
これらを判定するための各種イベントは、「検出結果」として記録され、Security Hub のコンソールから一覧、検索することができます。
クリックすると拡大します
以上が、Security Hub の基本的な機能です。
このソリューションをデプロイすることで、Security Hub が検出したセキュリティ基準に違反するリソースに対する修復アクションに必要な複数のコンポーネントが追加され、検出だけでなく、その修復までを素早く簡単に行うことができるようになります。ソリューションの概要を見ていきましょう。
ソリューションの概要
AWS ソリューション「AWS での自動化されたセキュリティ対応」は、AWS Security Hub を中心として、修復のために必要な IAM ロールや Lambda 関数など、複数のコンポーネントを内包したアドオンソリューションです。
Security Hub には、もともと事前定義されたセキュリティ基準に対する準拠状況を集約・可視化するための機能が備わっています。このソリューションによって、Security Hub が検出したセキュリティ基準に違反するリソースを修復するためのプレイブックとして、必要な各種リソースがデプロイされます。
通常であれば、セキュリティ基準の違反を検出したら、対象のリソースの設定を確認し、どう違反しているのかを特定した上で、修復の設定変更を行うのが一般的な流れだと思いますが、このソリューションを使えば、数クリックで、もしくは自動的に修復を実行することができるようになります。
さらに、修復結果を Amazon Simple Notification Service (SNS) を使って通知したり、Amazon CloudWatch Logs でログを残すこともできます。
ソリューションの内容や、構築手順、実装されている修復の内容など、詳細な情報は、このソリューションのウェブサイト からダウンロードできる、実装ガイド に記載されています。今回の構築でも使用しますので、ダウンロードして開いておきましょう。
なお、このソリューションは、以前は「AWS Security Hub の自動化された応答と修復」という名称でしたが、「AWS での自動化されたセキュリティ対応」に名称が変更されました。ドキュメント内で変更前の名称で記載されている場合がありますが、適宜読み替えてください。
本記事での構成
このソリューションは、マルチアカウント環境にも対応しています。セキュリティ管理に特化した Security Hub の管理者アカウントと、実際のワークロードが動作し、セキュリティ保護の対象となるメンバーアカウントのそれぞれに対し、AWS CloudFormation のテンプレートが提供されています。
本記事では、簡易的に単一の AWS アカウントにデプロイしますが、マルチアカウント環境へのデプロイ手順も実装ガイドに記載されています。また、AWS Organizations 環境で、StackSets を使った自動デプロイの設定手順も記載されているので、マルチアカウント環境に適用する際には参考にしてください。
今回は、セキュリティ基準として、「AWS 基礎セキュリティのベストプラクティス」を有効にして、ソリューションの適用と環境構築、違反したリソースの検出から修復までの流れをご紹介します。
事前準備
このソリューションでは、複数の Cloud Formation テンプレートが提供されていますが、それらを適用する前に、前提となる設定をいくつか行っておきます。
Security Hub の有効化
まずは Security Hub の有効化です。
AWS マネジメントコンソールから Security Hub を開き、「セキュリティ基準」で 「AWS 基礎セキュリティのベストプラクティス v1.0.0 を有効化」 を選択した状態で、 「Security Hub の有効化」 をクリックします。(すでに Security Hub と AWS 基礎セキュリティのベストプラクティス v1.0.0 のセキュリティ基準が有効化されている場合はこの手順は不要です)
クリックすると拡大します
AWS Config の有効化
AWS Config は AWS リソースの設定を評価、監査、審査できるサービスです。Config Rules という機能で、リソースが準拠すべきルールを記述することも可能で、Security Hub のセキュリティ基準のルールの多くは Config Rules で実現されています。
セキュリティ基準違反の検出に不可欠のサービスのため、事前に有効化しておきます。(すでに有効化されている場合はこの手順は不要です)
AWS マネジメントコンソールから AWS Config を開き、 「1-Click セットアップ」をクリックし、「レビュー」画面で「確認」をクリックして、AWS Config を有効化します。
クリックすると拡大します
CloudFormation テンプレートのデプロイ
ここから、このソリューションの本体とも言える、CloudFormation テンプレートをデプロイしていきます。
まず AWS マネジメントコンソールから CloudFormation コンソールを開き、左メニューのスタックを選択します。さらに画面右上の「スタックの作成」から「新しいリソースを使用 (標準)」をクリックします。
クリックすると拡大します
このソリューションでは、Cloud Formation テンプレートが 3 つ含まれています。
- コアソリューション : このソリューションのコアコンポーネントを含みます。
- メンバーアカウント : セキュリティ基準を適用するメンバーアカウント用の、修復のプレイブックなどのコンポーネントを含みます。
- メンバーロール : メンバーアカウント用の、修復アクションの実行に必要な IAM ロールを含みます。
以下のように、これらを順次デプロイしていきます。
1. コアソリューションのデプロイ
このソリューションの中核となる、修復アクションに必要なリソースが定義されたテンプレートです。マルチアカウント環境の場合は、AWS Security Hub の管理者アカウントで実行します。
クリックすると拡大します
ここでは、後者の Amazon S3 URL を指定する例を示します。
AWS マネジメントコンソールの「CloudFormation」の「スタックの作成」画面で、Amazon S3 URL にコピーした URL を貼り付け、「次へ」をクリックします。
クリックすると拡大します
「スタックの詳細を指定」画面で、「スタックの名前」に任意の名前 (例: aws-sharr-deploy) を入力し、「パラメータ」の「Security Standard Playbooks」 で、「LoadAFSBPAdminStack」以外の 2 つを「no」に変更し、「次へ」をクリックします。
Security Hub で別のセキュリティ基準を有効にして、それに対して修復アクションをインストールする場合は、「CIS AWS Foundations Benchmark」であれば 「LoadCIS120AdminStack」を、「PCI DSS」であれば「LoadPCI321AdminStack」をそれぞれ「yes」にします。
クリックすると拡大します
「スタックオプションの設定」画面では特に何も変更せず、「次へ」をクリックします。
クリックすると拡大します
「レビュー」画面では、画面最下部の「機能」で 「AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。」 および 「AWS Cloud Formation によって、次の機能が要求される場合があることを承認します。」の 2 つのチェックボックスにチェックを入れ、「スタックの作成」 をクリックします。
クリックすると拡大します
CloudFormation スタックの作成が始まります。ネストされたスタックを含め、すべてのスタックの作成が完了するのを待ちます。 (通常、数分で完了します)
2. メンバーアカウントのデプロイ
メンバーアカウント用の CloudFormation テンプレートです。コアソリューションと同様に、「スタックの作成」からテンプレートを使って CloudFormation スタックを作成します。先にコアソリューションのデプロイが完了している必要があります。
シングルアカウント環境の場合でも、このテンプレートをインストールする必要があります。マルチアカウント環境の場合は、Security Hub の管理者アカウント自身を含む、対象となるすべてのメンバーアカウントで行います。
コアソリューションと同様、実装ガイド から「メンバーアカウント」のテンプレートファイルの URL をコピーします。
クリックすると拡大します
AWS マネジメントコンソールの「CloudFormation」の「スタックの作成」画面で、Amazon S3 URL にコピーした URL を貼り付け、「次へ」をクリックします。
クリックすると拡大します
「スタックの詳細」画面の「パラメータ」では以下のように設定します。
- スタックの名前 : 任意の名前 (例: aws-sharr-member) を入力します。
- LogGroup Configuration : 今回のシナリオでは使用しませんが、AWS CloudTrail のログが記録される CloudWatch Logs ロググループを入力します。ここでは仮のロググループ名 (例: aws-sharr-log-group) を入力します
- Playbooks : LoadAFSBPMemberStack 以外の 2 つを no に変更します。
- その他のパラメータ : SecHubAdminAccount に Security Hub の管理者アカウントのアカウント ID を記入します。ここでは単一アカウントのため、現在の AWS アカウント ID を入力します。
クリックすると拡大します
「スタックオプションの設定」画面では何も変更せず、「次へ」をクリックします。
クリックすると拡大します
「レビュー」画面では、画面最下部の「機能」で「AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。」 および「AWS Cloud Formation によって、次の機能が要求される場合があることを承認します。」の 2 つのチェックボックスにチェックを入れ、「スタックの作成」をクリックします。
CloudFormation スタックの作成が始まります。ネストされたスタックを含め、すべてのスタックの作成が完了するのを待ちます。 (通常、数分で完了します)
クリックすると拡大します
3. メンバーロールのデプロイ
メンバーアカウントに必要な IAM ロールなどを含む CloudFormation テンプレートです。メンバーアカウントテンプレート同様、シングルアカウント、マルチアカウントに関わらず、Security Hub の管理者アカウント自身を含む、対象となるすべてのメンバーアカウントで行います。
コアソリューション、メンバーアカウントと同様、実装ガイド から「メンバーロール」のテンプレートファイルの URL をコピーします。
クリックすると拡大します
「CloudFormation」の「スタックの作成」画面で、Amazon S3 URL にコピーした URL を貼り付け、「次へ」をクリックします。
クリックすると拡大します
「スタックの詳細」画面の「パラメータ」では以下のように設定します。
- スタックの名前: 任意の名前 (例: aws-sharr-member-role) を入力します。
- SecHubAdminAccount : Security Hub の管理者アカウントのアカウント ID を記入します。ここでは単一アカウントのため、現在の AWS アカウント ID を入力します。
クリックすると拡大します
「スタックオプションの設定」画面では何も変更せず、「次へ」をクリックします。
クリックすると拡大します
「レビュー」画面では、画面最下部の「機能」で「AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。」のチェックボックスにチェックを入れ、「スタックの作成」をクリックします。
CloudFormation スタックの作成が始まりますので、完了するのを待ちます。
クリックすると拡大します
Amazon Simple Notification Service (SNS) サブスクリプションの作成 (オプション)
CloudFormation によって、修復に必要な一通りのコンポーネントは AWS 環境にデプロイされました。ここでは、修復時の通知先として、SNS サブスクリプションにメールアドレスを登録し、メールで通知がされるよう設定します。この手順は必須ではないため、不要であれば飛ばしても問題ありません。
AWS マネジメントコンソールから SNS コンソールを開きます。CloudFormation によって、1 個のトピックが作成されています。
クリックすると拡大します
メニューの「サブスクリプション」を開き、「サブスクリプションの作成」をクリックします。
「サブスクリプションの作成」画面では、「トピック ARN」 に CloudFormation によって作成された SNS トピックの ARN を選択します。
「プロトコル」には「E メール」を、「エンドポイント」には通知を受け取るメールアドレスを入力して、「サブスクリプションの作成」をクリックします。
クリックすると拡大します
この時点では、サブスクリプションは作成されていますが、まだ利用はできません。
しばらくすると、入力したメールアドレス宛に、「AWS Notification - Subscription Confirmation」 という Subject のメールが届くので、本文中の「Confirm subscription」 というリンクをクリックすることで確認が完了し、サブスクリプションが利用可能になります。
セキュリティ基準違反の検出と修復をやってみる
ここまでで、すべての準備は完了しました。いよいよ、セキュリティ基準に違反する設定の検出と、その修復をやってみようと思います。ここでは、セキュリティ基準に違反するリソース設定を行った上で、それが Security Hub で検出されたことの確認と、その修復を手動と自動、それぞれで実行します。
なお、このソリューションでは、セキュリティ基準のすべての項目に対して修復がサポートされているわけではありません。修復がサポートされているセキュリティ基準の項目については、実装ガイド のプレイブックの見出しで一覧が記載されています。
セキュリティ基準違反を手動で修復する
では、Security Hub でセキュリティ基準として有効化されている「AWS 基礎セキュリティのベストプラクティス v1.0.0」の項目に違反する設定をしてみます。ここでは、「EC2.2 VPC のデフォルトのセキュリティグループはインバウンドトラフィックとアウトバウンドトラフィックを許可しない必要があります」というものを見てみます。
VPC のデフォルトのセキュリティグループは、作成時点では、すべてのトラフィックを、自身のセキュリティグループをソースとする場合にのみ受け入れるインバウンドルールが設定されています。これを、HTTPS のインバウンドトラフィックを、0.0.0.0/0 から許可するルールに変更してみます。
注意: 意図的にベストプラクティスに反する設定を行うため、必ず影響のない環境で試すようにしてください。
AWS マネジメントコンソールから VPC のコンソールの「セキュリティグループ」を開きます。
対象となる VPC のデフォルトセキュリティグループを選択し、画面下部の「インバウンドルール」タブを選択します。
クリックすると拡大します
「ソース」がこのセキュリティグループの ID になっていることを確認した上で、「インバウンドルールを編集」をクリックします。(これによって、同じデフォルトセキュリティグループに属するリソースからのみ、インバウンドトラフィックを受け付ける状態になっています。)
クリックすると拡大します
「インバウンドのルールを編集」画面で、まず既存のルールを削除します。
クリックすると拡大します
「ルールの追加」をクリックします。
クリックすると拡大します
「タイプ」に「HTTPS」を、「ソース」に「Anywhere-IPv4」をそれぞれ選択し、「ルールの保存」をクリックします。
クリックすると拡大します
これによって、VPC のデフォルトセキュリティグループのインバウンドルールが、どこからでも HTTPS のインバウンドトラフィックを受け付けるようになり、セキュリティ基準に違反する状態になりました。
クリックすると拡大します
Security Hub のコンソールから、検出結果を確認します。(検出まで数分程度かかる場合があります)
「EC2.2 The VPC default security group should not allow inbound and outbound traffic」というタイトル行の、「コンプライアンスのステータス」が「FAILED」になっていることが分かります。
クリックすると拡大します
Security Hub のセキュリティ基準に違反する設定を検出することができました。続いて、この問題を修復してみましょう。
この検出結果の行のチェックボックスにチェックを入れた上で、「アクション」の 「Remediate with SHARR」をクリックします。
クリックすると拡大します
「検出結果を Amazon CloudWatchEvents へ正常に送信しました」というメッセージが表示されます。
修復のアクションが実行されたので、再度セキュリティグループを見てみましょう。
クリックすると拡大します
修復アクションによって、セキュリティ基準に違反していたインバウンドルールが削除されたことが分かります。(修復の完了まで数分程度かかる場合があります)
Security Hub 単体で利用している場合は、修復のための手順を Security Hub のドキュメントから参照して、修復する必要がありますが、このソリューションを利用することで、修復までのプロセスがこのように数クリックで完了します。
なお、SNS サブスクリプションを設定していた場合は、設定した宛先に通知が送信されます。配信されるメッセージは、以下のような JSON 形式のものです。
{
"severity": "INFO",
"message": "e33a92a3-2bfe-47e4-b439-e242a6a174cc: Remediation succeeded for AFSBP control EC2.2 in account xxxxxxxxxxxx: Security group closed successfully. (AwsEc2SecurityGroup sg-xxxxxxxxxxxxxxxxx)",
"finding": {
"finding_id": "ea580648-e3a1-4c66-9538-35e0c700571a",
"finding_description": "This AWS control checks that the default security group of a VPC does not allow inbound or outbound traffic.",
"standard_name": "aws-foundational-security-best-practices",
"standard_version": "1.0.0",
"standard_control": "EC2.2",
"title": "EC2.2 The VPC default security group should not allow inbound and outbound traffic",
"region": "ap-northeast-1",
"account": "xxxxxxxxxxxx",
"finding_arn": "arn:aws:securityhub:ap-northeast-1:xxxxxxxxxxxx:subscription/aws-foundational-security-best-practices/v/1.0.0/EC2.2/finding/ea580648-e3a1-4c66-9538-35e0c700571a"
}
}人間がそのまま読むには難がありますが、JSON 形式のため、SNS を通じて後続処理でのデータの抽出や加工がしやすくなっており、必要な情報をピックアップして、通知用のメッセージを作成するといったことがやりやすくなっています。
セキュリティ基準違反を自動で修復する
ここまでで、このソリューションによって、Security Hub が検出したセキュリティ基準に違反する状態を、修復アクションによって解消することができることが確認できました。ここからはこの修復が、自動で実行されるようにしてみましょう。
注意: 本番環境での自動修復の有効化は、修復アクションによって実行されるリソースの操作が、ワークロードの動作に影響を与える可能性も考慮して、慎重に行う必要があります。
自動修復は、Amazon EventBridge のルールによって実現されます。AWS マネジメントコンソールの EventBridge から、「ルール」を開きます。
実装ガイドでは、 Amazon CloudWatch Events と記載されていますが、CloudWatch Events は、その拡張版である EventBridge に移行されたため、ここでは EventBridge から操作を行います。
クリックすると拡大します
CloudFormation により、すでにルールが作成されていることが分かります。デフォルトでは、いずれもステータスが Disabled になっており、自動修復は無効化されています。これを有効化することによってセキュリティ基準に違反する設定を検出したら、自動的に修復アクションを開始することができます。それぞれのルールは、セキュリティ基準の項目 (ここでは、AWS 基礎セキュリティのベストプラクティス v1.0.0 で定義された項目) に対応しており、standard_control_AutoTrigger の命名規則で作成されています。
先程手動での修復を試した EC2.2 のルールを有効化してみます。検索ボックスに EC2.2 と入力し、表示される 「AFSBP_EC2.2_AutoTrigger」を選択して、「有効化」をクリックします。
クリックすると拡大します
確認のダイアログが表示されたら、「有効化」を選択し、「AFSBP_EC2.2_AutoTrigger」のステータスが「Enabled」になったことを確認します。
クリックすると拡大します
これで準備は完了です。先程と同じ手順で、VPC のデフォルトのセキュリティグループのインバウンドルールに、0.0.0.0/0 からの HTTPS トラフィックを許可するルールを追加してみましょう。
クリックすると拡大します
Security Hub の検出結果で、セキュリティ基準違反の検出を待ちます。
クリックすると拡大します
先程は、ここで明示的にアクションから修復の実行を行いましたが、今回は自動修復を有効化したため、セキュリティグループのルールは削除されているはずです。確認してみましょう。
クリックすると拡大します
手動で実行したときと同様、セキュリティグループからインバウンドルールが削除されていることが確認できました。
このようにして、Security Hub で検出されたセキュリティ基準に違反するデフォルトセキュリティグループのインバウンドルールの設定が、手動と自動それぞれで、迅速かつ簡単に修復できることが分かりました。
リソースの削除方法
CloudFormation スタックの削除
CloudFormation コンソールから、作成した 3 つの CloudFormation スタックを削除します。
メンバーロールに含まれる IAM ロールは、スタックを削除しただけでは消えないため、今回デプロイしたソリューション以外に SO0111-* の IAM ロールが使用されていないことを確認した上で、手動で削除します。
AWS Config と Security Hub の無効化 (オプション)
手動で有効化した AWS Config と Security Hub を必要に応じて無効化します。
AWS Config を無効化するには、 AWS マネジメントコンソールの AWS Config の「設定」を開き、「編集」をクリックします。
クリックすると拡大します
「設定の編集」画面で、記録を有効化のチェックを外すことで、以降の記録を停止することができます。
AWS Config は S3 にログを保存されるため、過去の履歴が不要であれば S3 バケットも削除します。
クリックすると拡大します
Security Hub を無効化するには、AWS マネジメントコンソールの Security Hub の設定を開き、「一般」タブの「AWS Security Hub の無効化」ボタンをクリックします。
クリックすると拡大します
CloudWatch Logs ロググループの削除 (オプション)
修復アクションの実行時には、CloudWatch Logs にログが出力されるため、これらの履歴が不要であれば、CloudWatch Logs ロググループを削除します。
AWS マネジメントコンソールから CloudWatch コンソールを開き、左メニューから「ロググループ」を選択します。ロググループの一覧に表示される、 SO0111-SHARR という文字列を名前に含むロググループが、このソリューションによって作成されたものです。
クリックすると拡大します
不要なロググループを選択し、「アクション」から「ロググループの削除」をクリックして、表示される確認ダイアログで「削除」をクリックします。
クリックすると拡大します
まとめ
今回は、AWS ソリューションの AWS での自動化されたセキュリティ対応 の構築手順と、実際のセキュリティ基準に違反する設定の検出から修復までの流れを試してみました。このソリューションによって、検出だけでなく、簡単に修復のアクションが実行でき、セキュリティリスクのある状態を短縮したり、対応のための運用負荷を削減できることがお分かりいただけたと思います。また、自動修復を有効化することで、検出から修復まで手動のオペレーションを介することなく対応ができます。
修復のプレイブックは、今回題材にしたデフォルトセキュリティグループの修復以外にも、90 日以上利用されていない IAM ユーザの認証情報の無効化や、パブリックで作成してしまった EBS スナップショットのプライベート化など、AWS 環境のセキュリティ統制や保護に役立つものが数多く含まれています。実装ガイド のプレイブックの項で、サポートされる修復内容が記載されているので、チェックしてみてください。
AWS 環境のセキュリティ統制をより万全なものとする選択肢として、ぜひこのソリューションをご活用ください。
筆者プロフィール
駒原 雄祐
アマゾン ウェブ サービス ジャパン合同会社
ソリューションアーキテクト
ソリューションアーキテクトとして、デジタルネイティブビジネスを展開されるお客様を中心に様々なお客様を支援しております。前職はインターネットメディア企業で、メディアサービスやアドテクノロジー領域のプロダクトの開発運用に、立ち上げ段階から数多く携わりました。
好きな AWS サービスは AWS WAF と Amazon CloudFront。
プライベートでは、2 児と 1 匹 (犬) のパパ業に悪戦苦闘しつつ、週末のテニスやゴルフ、家族旅行が日々の励みになっています。
AWS を無料でお試しいただけます