翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
CIS AWS Foundations Benchmark v1.4 Level 1 に関する運用上のベストプラクティス
コンフォーマンスパックは、マネージドルールまたはカスタム AWS Config ルールと AWS Config 修復アクションを使用して、セキュリティ、運用、またはコスト最適化のガバナンスチェックを作成できるように設計された汎用コンプライアンスフレームワークを提供します。サンプルテンプレートとしてのコンフォーマンスパックは、特定のガバナンスまたはコンプライアンス基準を準拠するようには設計されていません。お客様は、本サービスの利用が該当する法的要件および規制要件を満たしているかどうかについて、お客様自身で評価する責任を負います。
以下に、Center for Internet Security (CIS) Amazon Web Services Foundation v1.4 Level 1 と、 AWS マネージド Config ルール/AWS Config Process Checks 間のマッピングの例を示します。各 Config ルールが特定の AWS リソースに適用され、1 つ以上の CIS Amazon Web Services Foundation v1.4 Level 1 によるコントロールに関連付けられます。CIS の「Amazon Web Services Foundation v1.4 Level 1」によるコントロールを、複数の Config ルールに関連付けることができます。これらのマッピングに関する詳細およびガイダンスについては、以下の表を参照してください。
プロセスチェックの詳細については、「process-checks」を参照してください。
| コントロール ID | コントロールの概要 | AWS Config ルール | ガイダンス |
|---|---|---|---|
| 1.1 | 現在の連絡先情報を維持します | account-contact-details-configured （プロセスチェック） | AWS アカウントの連絡先の E メールと電話番号が最新のものであり、組織内の 1 人以上の個人にマッピングされていることを確認します。コンソールの [My Account] (マイアカウント) セクションで、[Contact Information] (連絡先情報) セクションに正しい情報が指定されていることを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 1.2 | セキュリティの連絡先情報が登録されていることを確認します。 | account-security-contact-configured （チェックの処理） | 組織のセキュリティチームの連絡先の E メールと電話番号が最新のものであることを確認します。 AWS マネジメントコンソールのマイアカウントセクションで、セキュリティセクションに正しい情報が指定されていることを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 1.4 | 「ルート」ユーザーのアクセスキーが存在しないことを確認する | ルートユーザーに AWS Identity and Access Management (IAM) ロールにアタッチされたアクセスキーがないことを確認することで、システムとアセットへのアクセスを制御できます。root アクセスキーが削除されていることを確認します。代わりに、ロールベースの AWS アカウントを作成して使用し、最小機能の原則を組み込むことができます。 | |
| 1.5 | MFA が「ルート」ユーザーで有効になっていることを確認する | ルートユーザーに対して MFA が有効になっていることを確認して、 AWS クラウド内のリソースへのアクセスを管理します。ルートユーザーは、 AWS アカウントで最も権限のあるユーザーです。MFA は、ユーザー名とパスワードに 1 つの保護レイヤーを追加します。ルートユーザーに MFA を要求することで、 AWS アカウントが侵害されるインシデントを減らすことができます。 | |
| 1.7 | 管理および日常のタスクでの「root」ユーザーの使用を排除します | root-account-regular-use （チェックの処理） | 日常的なタスクで、ルートアカウントを使用しないようにしてください。IAM で認証情報レポートを実行し、ルートユーザーが最後に使用された時期を調べます。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 1.8 | IAM パスワードポリシーにおいて 14 文字以上の長さが必要になります。 | ID と認証情報は、組織の IAM パスワードポリシーに基づいて発行、管理、検証されます。これらは、NIST SP 800-63 および AWS Foundational Security Best Practices 標準で規定されているパスワード強度の要件を満たしています。このルールでは、IAM パスワードポリシーにオプションで RequireUppercaseCharacters （AWS 基盤セキュリティのベストプラクティスの値: true) RequireLowercaseCharacters 、（AWS 基盤セキュリティのベストプラクティスの値: true) RequireSymbols 、（AWS 基盤セキュリティのベストプラクティスの値: true) RequireNumbers 、（AWS 基盤セキュリティのベストプラクティスの値: true) MinimumPasswordLength 、（AWS 基盤セキュリティのベストプラクティスの値: 14) PasswordReusePrevention、 (AWS 基盤セキュリティのベストプラクティスの値: 24)、および MaxPasswordAge (AWS 基盤セキュリティのベストプラクティスの値: 90) を設定できます。実際の値には、組織のポリシーを反映する必要があります。 | |
| 1.9 | IAM パスワードポリシーはパスワードの再使用を禁止しています | ID と認証情報は、組織の IAM パスワードポリシーに基づいて発行、管理、検証されます。これらは、NIST SP 800-63 および AWS Foundational Security Best Practices 標準で規定されているパスワード強度の要件を満たしています。このルールでは、IAM パスワードポリシーにオプションで RequireUppercaseCharacters （AWS 基盤セキュリティのベストプラクティスの値: true) RequireLowercaseCharacters 、（AWS 基盤セキュリティのベストプラクティスの値: true) RequireSymbols 、（AWS 基盤セキュリティのベストプラクティスの値: true) RequireNumbers 、（AWS 基盤セキュリティのベストプラクティスの値: true) MinimumPasswordLength 、（AWS 基盤セキュリティのベストプラクティスの値: 14) PasswordReusePrevention、 (AWS 基盤セキュリティのベストプラクティスの値: 24)、および MaxPasswordAge (AWS 基盤セキュリティのベストプラクティスの値: 90) を設定できます。実際の値には、組織のポリシーを反映する必要があります。 | |
| 1.10 | コンソールパスワードを持っているすべてのユーザーについて多要素認証 (MFA) が有効であることを確認します。 | コンソールパスワードを持つすべての AWS Identity and Access Management (IAM) ユーザーに対して MFA が有効になっていることを確認して、 AWS クラウド内のリソースへのアクセスを管理します。MFA は、サインイン認証情報に加えて更なる保護手段を追加します。ユーザーに MFA を要求することで、アカウントが侵害されるインシデントを減らし、権限のないユーザーが機密データにアクセスできないようにすることができます。 | |
| 1.11 | コンソールパスワードを持つすべてのユーザーの初期ユーザー集合アップ中にアクセスキーを集合アップしないでください | iam-user-console-and- api-access-at-creation （チェックの処理） | コンソールのパスワードを持つすべてのユーザーの初期設定時に、アクセスキーが設定されないようにします。コンソールにアクセスできるすべてのユーザーについて、ユーザーの「作成時刻」とアクセスキーの「作成日」を比較します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 1.12 | 45 日間以上使用されていない認証情報は無効にします。 | AWS Identity and Access Management (IAM) は、指定した期間に使用されていない IAM パスワードとアクセスキーをチェックすることで、アクセス許可と認可に役立ちます。これらの未使用の認証情報が特定された場合は、最小特権の原則に反する可能性があるため、その認証情報を無効にするか、削除する必要があります。このルールでは、値を maxCredentialUsageAge (CIS Standard 値: 45) に設定する必要があります。実際の値には、組織のポリシーを反映する必要があります。 | |
| 1.13 | 1 人のユーザーが使用できるアクティブなアクセスキーが 1 つのみであることを確認します。 | iam-user-single-access-key (チェックの処理） | 1 人のユーザーが使用できるアクティブなアクセスキーが 1 つのみであることを確認します。すべてのユーザーについて、[Security Credentials] (認証情報) タブで IAM の各ユーザーに使用されているアクティブなキーが 1 つのみであることを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 1.14 | アクセスキーは 90 日ごとに更新します。 | 組織のポリシーに従って IAM アクセスキーがローテーションされるようにすることで、認可されたデバイス、ユーザー、プロセスについての認証情報が監査されます。アクセスキーを定期的に変更することが、セキュリティのベストプラクティスです。これにより、アクセスキーがアクティブになっている期間が短縮され、キーが侵害された場合のビジネスへの影響を軽減できます。このルールでは、アクセスキーの更新の値が必要です (Config デフォルト: 90)。実際の値には、組織のポリシーを反映する必要があります。 | |
| 1.15 | ユーザーがグループを通してのみアクセス権を受け取るようにします。 | このルールにより、 AWS Identity and Access Management (IAM) ポリシーがグループまたはロールにのみアタッチされ、システムとアセットへのアクセスが制御されます。グループレベルまたはロールレベルで特権を割り当てると、ID が過剰な特権を受け取ったり保持したりする機会を減らすことができます。 | |
| 1.15 | ユーザーがグループを通してのみアクセス権を受け取るようにします。 | AWS Identity and Access Management (IAM) ユーザー、IAM ロール、または IAM グループに、システムおよびアセットへのアクセスを制御するインラインポリシーがないことを確認します。インラインポリシーの代わりに管理ポリシーを使用する AWS ことをお勧めします。管理ポリシーにより、再利用性、バージョニング、ロールバック、権限管理の委任が可能になります。 | |
| 1.15 | ユーザーがグループを通してのみアクセス権を受け取るようにします。 | AWS Identity and Access Management (IAM) は、ユーザーが少なくとも 1 つのグループのメンバーであることを確認することで、アクセス許可と認可を制限するのに役立ちます。タスク完了のために必要以上の権限をユーザーに許可することは、最小特権と職務の分離の原則に反する可能性があります。 | |
| 1.16 | 完全な「*:*」管理権限を許可する IAM ポリシーは作成されません。 | AWS Identity and Access Management (IAM) は、アクセス許可と認可に最小特権と職務分離の原則を組み込むのに役立ちます。これにより、ポリシーが「リソース」：「*」に対して「アクション」：「*」で「効果」：「許可」と「アクション」を含むことを制限できます。タスク完了のために必要以上の権限をユーザーに付与することは、最小特権と職務の分離の原則に反する可能性があります。 | |
| 1.17 | AWS サポートでインシデントを管理するためのサポートロールが作成されていることを確認する | AWS Identity and Access Management (IAM) は、IAM ポリシーが適切なユーザー、ロール、またはグループに割り当てられるようにすることで、アクセス許可と認可を管理するのに役立ちます。これらのポリシーを制限することは、最小特権と職務分離の原則も組み込まれています。このルールでは、 サポートによる AWS インシデント管理のためにAWSSupportAccess、policyARN を arn:aws:iam::aws:policy/ に設定する必要があります。 | |
| 1.19 | AWS IAM に保存されている期限切れの SSL/TLS 証明書が、すべて削除されていることを確認します。 | iam-expired-certificates （チェックの処理） | IAM に保存されている期限切れの SSL/TLS 証明書が、すべて削除されていることを確認します。 AWS CLI がインストールされているコマンドラインからAWS 「iam list-server-certificates」コマンドを実行し、期限切れのサーバー証明書があるかどうかを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 1.20 | AWS IAM Access Analyzer が有効になっていることを確認する | iam-access-analyzer-enabled （チェックの処理） | IAM Access Analyzer が有効になっていることを確認します。コンソールの [IAM] セクションで、[Access Analyzer] (アクセスアナライザー) を選択し、[STATUS] が [Active] (有効) に設定されていることを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください。 |
| 2.1.3 | S3 バケットで MFA Delete が有効であることを確認する。 | Amazon Simple Storage Service (Amazon S3) バケットのバージョニングは、同じ Amazon S3 バケットでオブジェクトの複数のバリアントを保持するのに役立ちます。S3バケットに多要素認証 (MFA) 削除を追加すると、バケットのバージョン状態を変更したり、オブジェクトのバージョンを削除したりするために、追加の認証要素が必要になります。MFA 削除により、万が一、セキュリティ認証が漏洩したり、不正なアクセスが行われた場合でも、セキュリティのレイヤーを追加することができます。 | |
| 2.1.5 | S3バケットに「パブリックアクセスをブロックする (バケット設定) 」が設定されていることを確認する | Amazon Simple Storage Service (Amazon S3) バケットにパブリックにアクセスできないようにすることで、 AWS クラウド内のリソースへのアクセスを管理します。このルールは、パブリックアクセスを防止することで、権限のないリモートユーザーから機密データを保護するのに役立ちます。このルールでは、オプションで ignorePublicAcls (Config デフォルト: True)、 blockPublicPolicy (Config デフォルト: True) blockPublicAcls 、(Config デフォルト: True)、および restrictPublicBuckets パラメータ (Config デフォルト: True) を設定できます。実際の値には、組織のポリシーを反映する必要があります。 | |
| 2.1.5 | S3バケットに「パブリックアクセスをブロックする (バケット設定) 」が設定されていることを確認する | Amazon Simple Storage Service (Amazon S3) バケットにパブリックにアクセスできないようにすることで、 AWS クラウド内のリソースへのアクセスを管理します。このルールでは、バケットレベルでのパブリックアクセスを防止することで、権限のないリモートユーザーから機密データを保護します。 | |
| 2.2.1 | EBSボリュームの暗号化が有効であることを確認します | 機密データが含まれている可能性があるため、保管中のデータを保護するために Amazon Elastic Block Store (Amazon EBS) ボリュームで暗号化が有効になっていることを確認します。 | |
| 2.2.1 | EBSボリュームの暗号化が有効であることを確認します | 保管中のデータを保護するため、Amazon Elastic Block Store (Amazon EBS) ボリュームで暗号化が有効になっていることを確認します。これらのボリュームには機密データが含まれている可能性があるため、保管時の暗号化を有効にしてデータを保護します。 | |
| 2.3.1 | RDSインスタンスで暗号化が有効であることを確認します | Amazon Relational Database Service (Amazon RDS) スナップショットで、暗号化が有効になっていることを確認します。機密データが含まれている可能性があるため、保管時の暗号化を有効にしてデータを保護します。 | |
| 2.3.1 | RDSインスタンスで暗号化が有効であることを確認します | 保管中のデータを保護するため、Amazon Relational Database Service (Amazon RDS) インスタンスで暗号化が有効になっていることを確認します。Amazon RDS インスタンスには機密データが含まれている可能性があるため、保管時の暗号化を有効にしてデータを保護します。 | |
| 3.1 | すべてのリージョンで CloudTrail が有効になっていることを確認する | AWS CloudTrail は、 AWS マネジメントコンソールのアクションと API コールを記録します。を呼び出したユーザーとアカウント AWS、呼び出し元のソース IP アドレス、および呼び出し日時を特定できます。 CloudTrail MULTI_REGION_CLOUD_TRAIL_ENABLED が有効になっている場合、 はすべての AWS リージョンから S3 バケットにログファイルを配信します。さらに、 が新しいリージョン AWS を起動すると、新しいリージョンに同じ証跡 CloudTrail が作成されます。その結果、アクションを実行しなくても、新しいリージョンの API アクティビティを含むログファイルを受け取ることができるようになります。 | |
| 3.3 | CloudTrail ログの保存に使用される S3 バケットがパブリックアクセス可能でないことを確認する | Amazon Simple Storage Service (Amazon S3) バケットへのアクセスのみを許可することで、 AWS クラウド内のリソースへのアクセスを管理します。アクセスの管理は、データの分類と一致している必要があります。 | |
| 3.3 | CloudTrail ログの保存に使用される S3 バケットがパブリックアクセス可能でないことを確認する | Amazon Simple Storage Service (Amazon S3) バケットへのアクセスのみを許可することで、 AWS クラウド内のリソースへのアクセスを管理します。アクセスの管理は、データの分類と一致している必要があります。 | |
| 3.3 | CloudTrail ログの保存に使用される S3 バケットがパブリックアクセス可能でないことを確認する | Amazon Simple Storage Service (Amazon S3) バケットにパブリックにアクセスできないようにすることで、 AWS クラウド内のリソースへのアクセスを管理します。このルールでは、バケットレベルでのパブリックアクセスを防止することで、権限のないリモートユーザーから機密データを保護します。 | |
| 3.4 | CloudTrail 証跡が Logs と CloudWatch統合されていることを確認する | Amazon CloudWatch を使用して、ログイベントアクティビティを一元的に収集および管理します。 AWS CloudTrail データを含めると、 AWS アカウント内の API コールアクティビティの詳細が提供されます。 | |
| 3.6 | S3 バケットで CloudTrail S3 バケットアクセスログ記録が有効になっていることを確認する | Amazon Simple Storage Service (Amazon S3) サーバーアクセスのログ記録によって、ネットワークをモニタリングし、潜在的なサイバーセキュリティイベントに対応することができます。Amazon S3 バケットに対して行われたリクエストの詳細な記録をキャプチャすることで、イベントをモニタリングします。各アクセスのログレコードから、1 つのアクセスリクエストについての詳細情報を取得できます。詳細情報には、リクエスタ、バケット名、リクエスト時刻、リクエストアクション、レスポンスのステータス、エラーコード (該当する場合) などの情報が含まれます。 | |
| 4.1 | 不正な API 呼び出しに対してログメトリクスフィルターとアラームが存在することを確認します | alarm-unauthorized-api-calls （チェックの処理） | 不正な API コールに対するログメトリクスフィルターとアラームが存在することを確認します このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 4.2 | MFA を使用しないマネジメントコンソールサインインに対してログメトリクスフィルターとアラームが存在することを確認します | alarm-sign-in-without-mfa (チェックの処理） | 多要素認証 (MFA) を使用しない AWS マネジメントコンソールのサインインに対するログメトリクスフィルターとアラームが存在することを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 4.3 | 「ルート」アカウントに対してログメトリクスフィルターとアラームが存在することを確認します | alarm-root-account-use （チェックの処理） | ルートアカウントに対するログメトリクスフィルターとアラームが存在することを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 4.4 | MFA なしの IAM ポリシーの変更に対してログメトリクスフィルターとアラームが存在することを確認します。 | alarm-iam-policy-change （チェックの処理） | IAM ポリシーの変更に対するログメトリクスフィルターとアラームが存在することを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 4.5 | CloudTrail 設定の変更に対してログメトリックフィルターとアラームが存在することを確認する | alarm-cloudtrail-config-change （チェックの処理） | CloudTrail 設定変更に対する AWS ログメトリクスフィルターとアラームが存在することを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 4.8 | S3 バケットの変更に対してログメトリクスフィルターとアラームが存在することを確認します | alarm-s3-bucket-policy-change （チェックの処理） | Amazon S3 バケットのポリシーの変更に対するログメトリクスフィルターとアラームが存在することを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 4.12 | ネットワークゲートウェイへの変更に対するログメトリクスとアラームが存在することを確認します | alarm-vpc-network-gateway-change (チェックの処理） | ネットワークゲートウェイへの変更に対するログメトリクスとアラームが存在することを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 4.13 | ルートテーブルの変更に対してログメトリクスフィルターとアラームが存在することを確認します | alarm-vpc-route-table-change (チェックの処理） | ルートテーブルの変更に対するログメトリクスフィルターとアラームが存在することを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 4.14 | VPC の変更に対してログメトリクスフィルターとアラームが存在することを確認します | alarm-vpc-change （チェックの処理） | Amazon Virtual Private Cloud (Amazon VPC) の変更に対するログメトリクスフィルターとアラームが存在することを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 4.15 | AWS Organizations の変更に対するログメトリクスフィルターとアラームが存在することを確認する | alarm-organizations-change （チェックの処理） | AWS Organizations の変更に対するログメトリクスフィルターとアラームが存在することを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください |
| 5.1 | ネットワーク ACL が 0.0.0.0/0 からリモートサーバー管理ポートへの侵入を許可していないことを確認します | ネットワーク ACL で、リモートサーバーの管理ポートへのパブリック Ingress が許可されていないことを確認します。コンソールの [VPC] セクションで、ソースが「0.0.0.0/0」のネットワーク ACL があり、リモートサーバーの管理者ポートを含むポートまたはポート範囲が許可されていることを確認します。このコントロールの監査の詳細については、https://www.cisecurity.org/benchmark/amazon_web_services/ で入手可能な「CIS の Amazon Web Services Foundations Benchmark version 1.4.0」のドキュメントを参照してください | |
| 5.2 | ネットワーク ACL が 0.0.0.0/0 からリモートサーバー管理ポートへの侵入を許可していないことを確認します。 | Amazon Elastic Compute Cloud (Amazon EC2) セキュリティグループは、 AWS リソースへの入力および出力ネットワークトラフィックのステートフルフィルタリングを提供することで、ネットワークアクセスの管理に役立ちます。リソースで 0.0.0.0/0 からポート 22 への入力 (またはリモート) トラフィックを許可しないようにすることで、リモートアクセスを制限できます。 | |
| 5.2 | ネットワーク ACL が 0.0.0.0/0 からリモートサーバー管理ポートへの侵入を許可していないことを確認します。 | Amazon Elastic Compute AWS Cloud (Amazon EC2) セキュリティグループで共通ポートが制限されるようにすることで、 クラウド内のリソースへのアクセスを管理します。ポートへのアクセスを信頼できるソースに制限しなければ、システムの可用性、完全性、機密性に対する脅威を招く可能性があります。このルールでは、blockedPort1～blockedPort5 パラメータ (CIS標準値: 3389) を任意に設定することができます。実際の値には、組織のポリシーを反映する必要があります。 |
テンプレート
テンプレートは、 GitHub: CIS AWS Foundations Benchmark v1.4 Level 1 に関する運用上のベストプラクティス
