AWS セキュリティグループ完全ガイド｜適切なトラフィック制御と設定のポイント
AWS でシステムを構築する際、ネットワークセキュリティの設定は欠かせません。不適切な設定は、不正アクセスやデータ漏洩のリスクを高めます。
インバウンドルールとアウトバウンドルールの違いや、接続トラブル時の原因特定など、実運用でつまずきやすいポイントを整理し、AWS セキュリティグループの基本から実践的な管理方法までを詳しく説明します。
AWS セキュリティグループとは
セキュリティグループの基本概念
仮想ファイアウォールとしての役割
AWS セキュリティグループは、Amazon Virtual Private Cloud（Amazon VPC）内のリソースへのトラフィックを制御する仮想ファイアウォールです。
Amazon EC2 インスタンス、Amazon RDS データベース、Elastic Load Balancing など、Amazon VPC 内のさまざまなリソースに適用できます。従来のネットワークファイアウォールと同様に、どのトラフィックを許可し、どのトラフィックを拒否するかを定義できます。
物理的な機器ではなくソフトウェアベースで動作するため柔軟な設定変更が可能であり、リソースのネットワークインターフェースレベルで機能します。
複数のセキュリティグループを1つのリソースに適用することも可能です。1つのネットワークインターフェースにつき、デフォルトで最大5つのセキュリティグループを適用できます（クォータ引き上げにより最大16まで増やせます）。
ステートフルな動作の特徴
重要な特徴として、ステートフルな動作が挙げられます。インバウンドルールで許可されたトラフィックに対する戻りトラフィックは、アウトバウンドルールに関係なく自動的に許可されます。
たとえばWebサーバーへのHTTPアクセス（ポート80）をインバウンドで許可した場合、サーバーからクライアントへの応答は自動的に許可されます。
明示的にアウトバウンドルールを設定する必要はありません。この仕組みによりルール設定が簡素化され、管理の負担を軽減できます。トラフィックの状態を記憶しているため、複雑な双方向の通信も適切に処理できます。
デフォルトの拒否ポリシー
デフォルトで拒否（deny by default）のポリシーを採用しています。
明示的に許可したトラフィックのみが通過し、それ以外のすべてのトラフィックは拒否されます。これは許可リスト方式（ホワイトリスト方式）と呼ばれ、セキュリティの観点から推奨されるアプローチです。
必要なトラフィックのみを許可することで、不正アクセスのリスクを最小限に抑えられます。拒否ルールを明示的に設定する必要はなく、許可ルールに該当しないトラフィックは自動的にブロックされます。
なお、セキュリティグループは強力な防御手段ですが、これ単体でセキュリティが完結するわけではありません。ネットワーク ACL や AWS WAF、IAM ポリシーなどと組み合わせた多層防御の考え方が重要です。詳細は後述の「多層防御の実装」セクションで解説します。
セキュリティグループの構成要素
インバウンドルール
リソースへの着信トラフィックを制御します。外部からリソースへのアクセスや、他のリソースからの通信を許可するルールを定義します。
各ルールには、プロトコル（TCP、UDP、ICMP など）、ポート範囲、ソース（送信元 IP アドレスまたはセキュリティグループ ID）を指定します。
TCP プロトコル、ポート80、ソース 0.0.0.0/0（すべての IP アドレス）というルールを設定すれば、すべての場所からの HTTP アクセスを許可できます。複数のインバウンドルールを設定することで、さまざまな種類のトラフィックを制御可能です。
アウトバウンドルール
リソースからの発信トラフィックを制御します。リソースから外部へのアクセスや、他のリソースからの通信を許可するルールを定義します。
デフォルトでは、すべてのアウトバウンドトラフィックが許可されています。セキュリティを強化する場合はこのデフォルトルールを削除し、必要な通信のみを許可する制限的な設定を行います。
各ルールには、プロトコル、ポート範囲、宛先（送信先 IP アドレスまたはセキュリティグループ ID）を指定します。
ルールの優先順位と評価
すべてのルールが同等の優先順位で評価されます。
複数のルールが存在する場合、いずれかのルールに一致すればトラフィックは許可されます。あるルールで特定の IP アドレスからのアクセスを許可し、別のルールでセキュリティグループからのアクセスを許可している場合、どちらか一方に一致すればトラフィックは通過します。
明示的な拒否ルールは存在せず、すべての許可ルールをチェックした後、いずれにも一致しなければ拒否されます。
セキュリティグループの作成と設定
セキュリティグループの作成手順
AWS マネジメントコンソールでの作成
AWS マネジメントコンソールにログインし、Amazon VPC サービスに移動します。
左側のメニューからセキュリティグループを選択し、作成ボタンをクリックします。設定画面が表示されたら、セキュリティグループ名、説明、紐づける Amazon VPC を指定します。
VPC の選択と命名規則
特定の Amazon VPC に関連付けられるため、適切なネットワーク環境を選択することが重要です。異なる Amazon VPC のリソースには同じセキュリティグループを使用できません。
セキュリティグループ名は、用途や適用対象がわかるように命名します。prod-web-alb-sg、dev-app-ec2-sg など、一目で役割がわかる名前を付けます。組織内で命名規則を統一することで、管理が容易になります。環境（本番、ステージング、開発）、レイヤー（Web、アプリケーション、データベース）、プロジェクト名などを組み合わせた命名が一般的なです。なお、セキュリティグループ名は作成後に変更できないため、命名規則を事前に定めておくことが重要です。
説明の記載
説明フィールドには、目的や用途を詳しく記載します。
Web サーバー用であり HTTP と HTTPS トラフィックを許可するなど、具体的な情報を記載します。説明は作成後に変更できないため、慎重に記載します。将来の運用管理を考慮して、わかりやすい説明を心がけます。
インバウンドルールの設定
プロトコルとポート範囲の指定
まずプロトコルを選択します。TCP、UDP、ICMP、またはすべてのトラフィックから選択できます。
Web サーバーの場合、HTTP は TCP プロトコルのポート80、HTTPS は TCP プロトコルのポート443を指定します。
カスタムポートを使用する場合は、カスタム TCP またはカスタム UDP を選択し、ポート番号を入力します。ポート範囲を指定することも可能です。8000-8100 と指定すれば、ポート8000から8100までのトラフィックが許可されます。
ソース IP アドレスの設定
トラフィックの送信元を指定します。IP アドレスまたは CIDR ブロックの形式で指定します。特定の IP アドレスのみを許可する場合は 192.0.2.10/32 のように記載し、IP アドレス範囲を許可する場合は 10.0.0.0/16 のように CIDR 表記を使用します。
すべての IP アドレスからのアクセスを許可する場合は 0.0.0.0/0 を指定します。ただし、すべての IP アドレスを許可する設定はセキュリティリスクが高いため、必要最小限に留めることが重要です。
セキュリティグループ ID の参照
IP アドレスの代わりにセキュリティグループ ID を指定することもできます。これにより、特定のセキュリティグループが適用されたリソースからのトラフィックを許可できます。
Web サーバーのセキュリティグループで、アプリケーションサーバーのセキュリティグループ ID をソースに指定すると、アプリケーションサーバーからの通信のみが許可されます。IP アドレスが動的に変わる環境でも、セキュリティグループ ID を使えば管理が容易になります。マイクロサービスアーキテクチャではこの参照方式が特に有効です。
アウトバウンドルールの設定
デフォルトのアウトバウンドルール
作成直後は、デフォルトですべてのアウトバウンドトラフィックを許可するルールが設定されています。プロトコルはすべてのトラフィック、宛先は 0.0.0.0/0 となっています。
多くの場合、このデフォルト設定で問題ありません。リソースから外部へのアクセスが制限されず、必要な通信ができます。
制限的なアウトバウンド設定
セキュリティを強化する場合は、デフォルトのアウトバウンドルールを削除し、必要な通信のみを許可します。データベースサーバーでは、アプリケーションサーバーへの応答のみを許可し、外部への通信は制限します。
アウトバウンドを制限することで、万が一リソースが侵害された場合でも、外部への不正な通信を防ぐ効果が期待できます。
宛先の指定方法
宛先はインバウンドルールのソースと同様に指定します。IP アドレス、CIDR ブロック、またはセキュリティグループ ID を使用できます。
特定のサービスへの通信のみを許可する場合は、そのサービスの IP アドレス範囲を指定します。Amazon S3 や Amazon DynamoDB などのマネージドサービスと通信する場合は、Amazon VPC エンドポイントの使用も有効です。
セキュリティグループの適用と管理
リソースへの適用
EC2 インスタンスへの適用
Amazon EC2 インスタンスの起動時に適用するセキュリティグループを選択できます。インスタンス起動ウィザードのネットワーク設定セクションで指定します。
既存のインスタンスに適用する場合は、コンソールからインスタンスを選択し、アクションメニューのセキュリティ設定から変更できます。
RDS データベースへの適用
Amazon RDS データベースインスタンスの作成時にセキュリティグループを選択します。接続セクションで Amazon VPC とセキュリティグループを指定します。
既存のデータベースインスタンスのセキュリティグループを変更する場合は、コンソールで変更ボタンをクリックします。変更は即座に適用するか、次のメンテナンスウィンドウで適用するかを選択できます。
複数リソースへの一括適用
同じセキュリティポリシーを複数のリソースに適用する場合、同一のセキュリティグループを使用します。複数の Web サーバーインスタンスに同じセキュリティグループを適用することで、一元的な管理が可能になります。
ルールの変更は、そのセキュリティグループが適用されているすべてのリソースに反映されるため、個別に設定を変更する手間が省けます。
セキュリティグループの変更と更新
ルールの追加と削除
既存の設定にルールを追加する場合、対象のセキュリティグループを選択してインバウンドルールまたはアウトバウンドルールを編集します。新しいルールの追加や、不要になったルールの削除を直感的に操作できます。複数のルールをまとめて編集することも可能です。
変更の即時反映
ルールの変更はリソースを停止せずに実施でき、即座に反映されます。ダウンタイムが発生しないため、運用中のシステムでも設定を更新できます。
変更後のルールが意図した通りに動作するか、十分に確認することが重要です。誤った設定により、必要な通信がブロックされる可能性があります。
変更履歴の確認
変更履歴は AWS CloudTrail に記録されます。誰がいつ、どのような変更を行ったかを確認できます。
履歴を定期的にレビューすることで、不適切な変更やセキュリティリスクのある設定を早期に発見できます。
複数のセキュリティグループの組み合わせ
レイヤー別のセキュリティグループ設計
アプリケーションのレイヤーごとにセキュリティグループを分けることで、管理が容易になります。Web レイヤー、アプリケーションレイヤー、データベースレイヤーでそれぞれ異なるグループを作成します。
Web レイヤーでは HTTP と HTTPS トラフィックを許可し、アプリケーションレイヤーでは Web レイヤーからの通信のみを許可します。データベースレイヤーではアプリケーションレイヤーからの通信のみを許可します。このような段階的な制御により、セキュリティ基盤が強固になります。
役割別の分離
共通の機能や役割ごとに分離することも有効です。SSH アクセス用、監視システム用、バックアップシステム用など、役割ごとに定義します。
1つのリソースに複数のセキュリティグループを適用することで、レイヤー別のルールと役割別のルールを柔軟に組み合わせることができます。
組み合わせ時の評価ルール
複数のセキュリティグループが適用されている場合、すべてのルールが評価されます。いずれかで許可されていればトラフィックは通過します。
OR 条件で評価されるため柔軟なアクセス制御が可能になりますが、意図しない通信が許可されないようルール全体を俯瞰して管理することが重要です。
セキュリティグループのベストプラクティス
最小権限の原則
必要最小限のポート開放
必要なポートのみを開放し、不要なポートは閉じておきます。Web サーバーであればポート80と443のみを開放します。
管理用のポート（SSH の22、RDP の3389）は、特定の IP アドレスからのアクセスのみに制限します。すべての IP アドレスに対して開放すると、ブルートフォース攻撃のリスクが高まります。
IP アドレス範囲の限定
可能な限り、IP アドレス範囲を限定します。社内ネットワークからのアクセスのみを許可する場合は、社内の IP アドレス範囲を指定します。
0.0.0.0/0 は、パブリックに公開する Web サーバーなど必要な場合に限定して使用します。
定期的なルール見直し
ルールを定期的に見直し、不要になった設定は削除します。プロジェクトの終了やシステム変更により、不要なルールが残っている場合があります。
四半期に一度など、定期的なレビューのスケジュールを設定することをおすすめします。
セキュリティグループの命名と管理
わかりやすい命名規則
用途や適用対象が一目でわかるように命名します。環境、レイヤー、用途などを組み合わせた命名が推奨されます。
本番環境の Web レイヤーのロードバランサー用であれば prod-web-alb-sg といった形です。組織全体で命名規則を統一することで、管理の手間を軽減できます。
タグの活用
タグを付けることで、分類や検索が容易になります。Environment タグで本番環境や開発環境を示し、Project タグでプロジェクト名を示します。
Owner タグで担当チームを示すことで、問い合わせ先が明確になります。コスト配分の観点からも、タグの活用は有効です。
ドキュメント化
設計思想や設定内容をドキュメント化します。各グループの目的、適用対象、ルールの意図を記録します。
ネットワーク図に配置を示すことで、全体像が把握しやすくなります。新しいメンバーの参加やトラブルシューティングの際にドキュメントが役立ちます。
セキュリティグループ同士の参照活用
動的な IP 管理の回避
セキュリティグループ ID を参照することで、IP アドレスの動的な変更に対応できます。Amazon EC2 インスタンスの IP アドレスが変わっても、設定を変更する必要がありません。
オートスケーリングでインスタンスが増減する環境では特に有効です。新しいインスタンスに同じグループを適用すれば、自動的に適切な通信が許可されます。
マイクロサービス間の通信制御
マイクロサービスアーキテクチャでは、サービスごとにセキュリティグループを作成し、サービス間の通信を参照で制御します。API ゲートウェイ、認証サービス、データサービスをそれぞれ分離します。
各サービスのインバウンドルールで、通信を許可する他のサービスの ID を指定します。これによりサービス間の依存関係が明確になり、セキュアな設計を維持できます。
IAM ロールと組み合わせたセキュアなアクセス制御
アクセスキーを使用しない認証
AWS IAM ロールを使用することで、アクセスキーやパスワードを使用せずにセキュアな認証を実現できます。Amazon EC2 インスタンスに IAM ロールを割り当てることで、一時的な認証情報が自動的に発行および更新されます。
長期的な認証情報の漏洩リスクを回避できます。ネットワークレベルの制御はセキュリティグループで、アプリケーションレベルの制御は IAM ロールで行うことで、多層防御が実現します。クロスアカウントアクセスの際も、IAM ロールによる認証が有効です。
Secrets Manager によるパスワード管理とローテーション
データベースなどの認証情報は、AWS Secrets Manager で管理します。AWS Secrets Manager は、パスワードの暗号化保存、自動ローテーション、アクセス制御を提供します。
データベースへのネットワークアクセスを制限し、IAM ロールで AWS Secrets Manager へのアクセスを制御します。定期的な自動ローテーションにより、パスワード漏洩のリスクを低減し、コンプライアンス要件にも対応できます。
よくあるセキュリティリスクと対策
0.0.0.0/0 の過度な使用
すべての IP アドレスをソースに指定すると、インターネット上のすべての場所からのアクセスが許可されます。SSH や RDP に対してこの設定を行うと、不正アクセスのリスクが大きく高まります。
管理用ポートは特定の IP アドレスや VPN 経由のアクセスのみに制限し、パブリックに公開する必要があるサービス以外での使用を避けます。
不要なポートの開放
必要以上のポートを開放すると、攻撃の対象が増えます。デフォルトで開放されているポートや、テスト目的で一時的に開放したポートがそのまま残っているケースが見受けられます。
定期的にルールを見直し、アプリケーションが使用するポートを正確に把握して、必要最小限のポートのみを開放します。
デフォルト設定の放置
Amazon VPC のデフォルトセキュリティグループは、同じグループが適用されたリソース間の通信を許可します。意図しない通信が許可される可能性があるため、デフォルトは使用せず専用のグループを作成することが推奨されます。
また、すべてのアウトバウンドを許可するデフォルトルールも、要件に応じて適切に制限します。
段階的な導入アプローチ
セキュリティグループの設計と運用を安全かつ確実に行うためには、段階的なアプローチが推奨されます。
- Phase1: 小規模テスト（PoC）から始める
まずは開発環境や特定のWebサーバーなど限定的なリソースから適用を開始します。必要な通信要件を洗い出し、最小権限のルールを設定して通信が正常に行われるかを確認します。 - Phase2: 効果検証と改善
Amazon CloudWatch Logs などを活用してトラフィックをモニタリングします。ブロックされた正当な通信がないか、あるいは不要なポートが空いていないかを検証し、ルールをチューニングします。 - Phase3: 本格展開と組織浸透
検証済みのセキュリティグループ設計を本番環境や他のシステムに横展開します。運用ルールのドキュメント化や命名規則の標準化を行い、組織全体で一貫した管理体制を構築します。
多層防御の実装
WAF との組み合わせ
AWS WAF と組み合わせることで、アプリケーション層とネットワーク層の両方で防御できます。ネットワークレベルのトラフィックを制御し、AWS WAF で SQL インジェクションや XSS などのアプリケーションレベルの攻撃を防ぎます。
ロードバランサーに AWS WAF を適用し、その背後の Web サーバーにセキュリティグループを適用することで、段階的な防御が実現します。
暗号化の強化
アクセス制御に加えて、データの暗号化を実施します。転送中のデータは TLS や SSL で暗号化し、保存されたデータは AWS KMS（AWS Key Management Service）で暗号化します。
ネットワークアクセスを制限し、暗号化でデータの機密性を保護することで、包括的なセキュリティを実現します。
アクセス制御の厳格化
セキュリティグループ、AWS IAM ポリシー、リソースベースのポリシーを組み合わせてアクセス制御を厳格化します。ネットワークレベルの制御を行いつつ、AWS IAM でユーザーやロールのアクセス権限を管理します。
Amazon S3 バケットや AWS Lambda 関数などのリソースには、リソースベースのポリシーでさらに細かい制御を設定します。多層の制御により、セキュリティリスクを最小限に抑えられます。
導入による ROI・効果測定の例
適切な設計と運用自動化を組み合わせることで、セキュリティ強化だけでなく運用コストの最適化も期待できます。
コストと工数の削減例
前提条件
- 月間50回のサーバー構築や構成変更が発生する環境
- ネットワーク担当者が手動でポートとIPの申請を確認・設定
導入前の課題
- 1回あたり約30分の確認および手動設定が発生
- 人為的ミスによる通信トラブルとその調査に時間がかかる
導入後の効果
- セキュリティグループ同士の参照を活用した標準化により、IPアドレス管理の手間が不要になります。
- IaC（Infrastructure as Code）を用いた自動プロビジョニングとの組み合わせで、手動設定にかかる月間約25時間の工数を削減できます。
- 設定ミスに起因するトラブル対応時間が大幅に縮小され、運用チームがより生産的な業務に集中できる環境を構築できます。
セキュリティグループとネットワーク ACL の比較
動作の違い
ステートフル vs ステートレス
セキュリティグループはステートフルに動作します。インバウンドで許可したトラフィックの戻りトラフィックは自動的に許可されます。
対して、ネットワーク ACL はステートレスです。インバウンドとアウトバウンドのルールを個別に設定する必要があり、戻りトラフィックも明示的に許可しなければなりません。
参照：ネットワークアクセスコントロールリストを使用して、サブネットのトラフィックを制御する
評価の順序
セキュリティグループでは、すべてのルールが同等の優先順位で評価されます。いずれかのルールに一致すればトラフィックは許可されます。
ネットワーク ACL では、ルール番号の小さい順に評価されます。最初に一致したルールが適用され、それ以降のルールは評価されません。また、明示的な許可ルールと拒否ルールの両方を設定できるという特徴があります。
使い分けの基準
セキュリティグループが適している場合
Amazon EC2 インスタンスや Amazon RDS など、リソース単位での個別のアクセス制御にはセキュリティグループが適しています。
ステートフルな動作によりルール設定が簡素化され、アプリケーションの要件に応じた柔軟な制御が可能です。
ネットワーク ACL が適している場合
サブネット全体への一括的な制御や、特定の IP アドレスからのトラフィックを明示的に拒否する場合は、ネットワーク ACL が適しています。
明示的な拒否ルールを設定できるため、既知の悪意ある IP アドレスからのアクセスをサブネットレベルでブロックする用途に有効です。
併用による多層防御
両者を併用することで、多層防御を実現できます。ネットワーク ACL でサブネットレベルの大まかな制御を行い、セキュリティグループでリソースレベルの詳細な制御を行います。
ネットワーク ACL で既知の脅威を弾き、セキュリティグループでアプリケーション要件に応じた細やかな制御を行うことで、セキュリティ基盤全体が強化されます。
トラブルシューティングと監視
接続問題の診断
VPC フローログの確認
Amazon VPC Flow Logs を有効にすることで、ネットワークインターフェースを出入りするトラフィック情報を記録できます。Amazon CloudWatch Logs や Amazon S3 にログを保存して分析します。
フローログから、トラフィックが許可されたか拒否されたかを確認できます。拒否が確認された場合は、セキュリティグループとネットワーク ACL の各設定を照合することで、どちらが原因かを切り分けることができます。
参照：VPC フローログを使用した IP トラフィックのログ記録
セキュリティグループルールの確認
接続できない場合、まずルールを確認します。必要なポートが開放されているか、ソース IP アドレスが正しく設定されているかをチェックします。
複数のセキュリティグループが適用されている場合は、すべてのルールを確認し、意図しない設定がないかを調査します。
一般的な接続エラーの原因
一般的な原因として、必要なポートが開放されていない、ソース IP アドレスの指定が間違っている、ネットワーク ACL で拒否されている、ルートテーブルの設定が間違っているなどが挙げられます。
これらを順番に確認することで原因を特定できます。Amazon VPC Reachability Analyzer を使用してネットワークの到達可能性を診断するアプローチも有効です。
セキュリティグループの監視
CloudTrail による変更監視
AWS CloudTrail は、変更イベントを自動的に記録します。誰がいつ、どのような変更を行ったかを追跡できます。
イベント履歴から、ルールの追加や削除に関する操作を検索し、不適切な変更が行われていないかを定期的に確認します。
ニアリアルタイムでのセキュリティ設定変更検知
CSPM（Cloud Security Posture Management）ツールを活用することで、設定変更をニアリアルタイムで検知できます。ルールが変更されるたびに自動でチェックが実行されます。
コンプライアンスに違反する変更が行われた場合、即座に担当者へ通知されるため、準拠違反の状態が放置されることを防ぎます。
CSPM ツールを活用した準拠違反の即時検知
CSPM ツールにより、設定がベストプラクティスやコンプライアンス基準に準拠しているかを継続的にチェックできます。0.0.0.0/0 が SSH ポートに設定されているといった問題を自動検知します。
設定変更時のリアルタイム検知によりインシデントを防ぐだけでなく、実運用では SSH の直接開放を避け、AWS Systems Manager Session Manager を経由したアクセスへ移行したり、VDI（Amazon WorkSpaces）等の仮想環境を利用してローカルへのデータ保存を禁止するなど、データ持ち出し策とセットで運用することが重要です。
オープンソースツールによるルール管理
Falco などのオープンソースのランタイムセキュリティプラットフォームを活用することで、検知の判断基準を透明性高く管理できます。
自社の環境に合わせてルールのチューニングを行い、不要なアラートを減らすことで運用負荷を軽減できます。
不適切な変更の検知とアラート設定
Amazon EventBridge と Amazon SNS を組み合わせることで、変更時にアラートを送信できます。特定のルール変更を検知した場合に、即座に通知を受け取ることが可能です。
AWS Lambda 関数を組み合わせることで、不適切な変更を自動的に元に戻す自動修復の仕組みを構築し、セキュリティリスクを素早く軽減できます。
定期的なセキュリティ監査
設定を定期的に監査します。AWS Config を使用して設定履歴を記録し、ルールに準拠しているかを評価します。
AWS Security Hub を活用して複数のセキュリティサービスの結果を統合し、包括的に評価することで、継続的なセキュリティ向上を実現します。
最後に
AWS セキュリティグループは、Amazon VPC 内のリソースへのトラフィックを制御する重要な仮想ファイアウォールです。ステートフルな動作やデフォルトの拒否ポリシーを正しく理解し、最小権限の原則に基づくルール設計を行うことで、強固なネットワークセキュリティを実現できます。
段階的な導入から始め、ルール見直しのサイクルを回すとともに、AWS IAM ロールや多層防御の実装、CSPM による継続的な監視を組み合わせることで、より安全なシステム運用が可能になります。
cloudpack では、AWS セキュリティグループの設計をはじめとした、セキュアなネットワーク環境の導入・構築を支援しています。要件定義から運用自動化、セキュリティ監査までトータルでサポートいたします。AWS でのインフラ設計やセキュリティ対策にお悩みの際は、ぜひお気軽にご相談ください。