© 2020, Amazon Web Services, Inc. or its affiliates リージョンの選択 ワークロードにリージョンを選択する方法は? SUS 1 ワークロードのためのリージョンの選択は パフォーマンス コスト カーボンフットプリントなどの KPI に大きく影響します これらの KPI を効果的に改善するには ビジネス要件と持続可能性の目標の両方に基づいて ワークロードのリージョンを選択する必要があります … リージョンの選択 需要に合わせた調整 クラウドリソースを需要に合わせる方法は? SUS 2 ユーザーとアプリケーションがワークロードやその他のリソースを使用する方法によって 持続可能性の目標を達成するための改善点を特定できます 継続的に需要に合うようにインフラストラクチャをスケールし ユーザーをサポートするために必要な最小リソースのみを使用していることを検証します サービスレベルをお客様のニーズと整合させます ユーザーとアプリケーションがリソースを消費するために必要なネットワークを制限できるようにリソースを配置します 未使用のアセットを削除します チームメンバーには ニーズをサポートし持続可能性への影響を最小限にするデバイスを提供します … 需要に合わせた調整 ソフトウェアとアーキテクチャ ソフトウェアとアーキテクチャのパターンをどのように利用して、持続可能性目標を目指しますか? SUS 3 負荷平滑化を実行しデプロイされたリソースが一貫して高使用率で維持されるパターンを実装し リソースの消費を最小化します 時間の経過とともにユーザーの行動が変化したため コンポーネントが使用されずアイドル状態になることがあります パターンとアーキテクチャを改定して 使用率の低いコンポーネントを統合し 全体の使用率を上げます 不要になったコンポーネントは使用停止にします ワークロードコンポーネントのパフォーマンスを理解し リソースの消費が最も大きいコンポーネントを最適化します 顧客がお客さまのサービスにアクセスするために使用するデバイスを把握し デバイスをアップグレードする必要性を最小化するパターンを実装します … ソフトウェアとアーキテクチャ データ データ管理のポリシーとパターンをどのように利用して、持続可能性目標を達成しますか? SUS 4 データ管理プラクティスを実装して ワークロードのサポートに必要なプロビジョンされたストレージと それを使用するために必要なリソースを削減します データを理解し データのビジネス価値とデータの使用方法を最もよくサポートするストレージテクノロジーと設定を使用します 必要性が小さくなった場合はより効率的で性能を落としたストレージにデータをライフサイクルし データが不要になった場合は削除します … データ ハードウェアとサービス アーキテクチャでクラウドのハードウェアとサービスをどのように選択して、持続可能性目標を達成しますか? SUS 5 ハードウェア管理のプラクティスを変更することで ワークロードの持続可能性に対する影響を軽減する機会を探します プロビジョンおよびデプロイする必要があるハードウェア数を最小化し 個別のワークロードにおいて最も効率のいいハードウェアとサービスを選択します … ハードウェアとサービス プロセスと文化 組織のプロセスは、持続可能性目標の達成にどのように役立ちますか? SUS 6 開発 テスト デプロイのプラクティスを変更することで 持続可能性に対する影響を減らす機会を探します … プロセスと文化 事業活動が環境的、経済的、社会的に及ぼす長期的な影響。国際連合の「環境と開発に関する世界委員会」は、持続可能な開発を「将来の世代のニーズを満たす能力を損なうことなく、現在のニーズを満たす開発」と定義しています。 お客様の企業または組織が、環境によくない影響を与える可能性があります。直接的または間接的な炭素排出量、再利用できない廃棄物、清浄水などの共有資源に対するダメージなどです。 サステナビリティ クラウド財務管理 クラウド財務管理はどのように実装しますか? COST 1  クラウドの導入により 承認 調達 インフラストラクチャのデプロイサイクルが短縮されるため 技術チームは イノベーションをより迅速に起こすことができます ビジネス価値と財務的な成功を実現するには クラウドでの財務管理に対する新たなアプローチが必要です このアプローチとはクラウド財務管理であり 組織全体での知識の蓄積 プログラム リソース プロセスを実装することで 組織全体の機能を構築します 多くの組織は 異なる優先順位を持つ多数の異なる単位で構成されています 合意された一連の財務目標に整合するように組織を調整し それらを満たすメカニズムを組織に提供することで より効率的な組織を構築できます 有能な組織は より迅速にイノベーションを進め より迅速に構築し より俊敏になり 内部的または外部的要因に合わせて自らを調整します … クラウド財務管理を実践する 使用状況ガバナンス 使用状況をどのように管理しますか? COST 2 使用状況とコストのモニタリング コストと使用量はどのように監視すればよいでしょうか? COST 3 リソースを削除する 不要なリソースをどのように削除しますか？ COST 4 クラウドによる柔軟性と俊敏性の向上は イノベーションを促進し 開発とデプロイのペースを高めます クラウドによってオンプレミスインフラストラクチャのプロビジョニングに関連した手動プロセスや時間を省くことができます これにはハードウェア仕様の決定 価格交渉 注文管理 発送のスケジュール設定 リソースのデプロイなどが含まれます ただし この使いやすさと事実上無限のオンデマンドキャパシティーを生かすには 費用に対する新しい考え方が必要になります 多くのビジネスは さまざまなチームが運用する複数のシステムによって構成されています リソースのコストをそれぞれの組織や製品オーナーに帰属させることができると リソースを効率的に使用し 無駄を削減できます コストの帰属を明確にすることで 実際に利益率の高い製品を把握し 予算の配分先についてより多くの情報に基づいた決定ができるようになります … 経費支出と使用量の認識 サービスの選択 サービスを選択するとき、どのようにコストを評価しますか? COST 5 リソースタイプ、リソースサイズ、およびリソース数を選択する コストターゲットに合わせて、リソースタイプ、リソースサイズ、およびリソース数を選択するには、どうすればよいですか? COST 6 料金モデルの選択 コストを削減するには、料金モデルをどのように使用したらよいでしょうか? COST 7 データ転送の計画 データ転送料金についてどのように計画していますか？ COST 8 ワークロードにとって適切なインスタンスとリソースを使用することが コスト削減の鍵になります たとえば レポート処理を小規模なサーバーで実行すると 5 時間かかるものの 費用が 2 倍の大規模なサーバーでは 1 時間で実行できるとします どちらのサーバーでも同じ結果が得られますが 長期的に見れば小規模なサーバーで発生するコストの方が大きくなります 優れた設計のワークロードでは最もコスト効率の良いリソースが使用されるため 大幅にプラスの経済的影響が生じます また マネージドサービスを使用することで コストを削減できる場合もあります 例えば E メールを配信するためにサーバーを保守することなく メッセージ単位で料金が発生するサービスを使用できます … 費用対効果の高いリソース 需要を管理し、リソースを供給する どのように需要を管理し、リソースを供給しますか? COST 9 クラウドに移行すると お支払いは必要な分のみになります 必要な時にワークロードの需要に合わせたリソースを供給できるため コストがかかる無駄なオーバープロビジョニングの必要性を排除できます また スロットル バッファ またはキューを使用して 需要を調整し 少ないリソースで供給することで コストを削減したり 後でバッチサービスで処理したりできます … 需要を管理しリソースを供給する 新しいサービスの評価 新しいサービスをどのように評価していますか？ COST 10 労力コストを評価する 労力コストを評価する方法は何ですか? COST 11 AWS では新しいサービスと機能がリリースされるため 既存のアーキテクチャの決定をレビューし 現在でもコスト効率が最も優れているかどうかを確認することがベストプラクティスです 要件の変化に応じて 不要になったリソース サービス全体 システムを積極的に廃止してください … 継続的最適化 最も低い価格でシステムを運用してビジネス価値を実現する能力。 コスト最適化 アーキテクチャの選択 ワークロードに適したクラウドリソースとアーキテクチャパターンを選択する方法を教えてください。 PERF 1 特定のワークロードに適したソリューションはさまざまで 大抵の場合 ソリューションには複数のアプローチが組み合わされています 優れた設計のワークロードは 複数のソリューションを使用し 異なる機能を使ってパフォーマンスを向上させます … アーキテクチャの選択 コンピューティングとハードウェア コンピューティングリソースを選択し、ワークロードで使用するにはどうすればよいでしょうか? PERF 2 特定のワークロードに対する最適なコンピューティングの選択は アプリケーションの設計 利用パターン および構成設定に応じて異なります アーキテクチャでは 各種コンポーネントに異なるコンピューティングを使用し 異なる機能を有効化してパフォーマンスを向上させることができます アーキテクチャに誤ったコンピューティングを選択することは パフォーマンス効率の低下につながる可能性があります … コンピューティングとハードウェア データ管理 ワークロード内のデータはどのように保存、管理、アクセスすればよいでしょうか? PERF 3 特定のシステムに最適なデータ管理ソリューションは データの種類 ブロック ファイル またはオブジェクト アクセスパターン ランダムまたはシーケンシャル 必要なスループット アクセス頻度 オンライン オフライン アーカイブ 更新頻度 WORM 動的 および可用性と耐久性に関する制約に応じて異なります 優れた設計のワークロードは さまざまな機能によってパフォーマンスを向上させることができる専用のデータストアを使用します … データ管理 ネットワークとコンテンツ配信 ワークロード内のネットワークリソースはどのように選択して設定すればよいでしょうか? PERF 4 ワークロードに最適なネットワークソリューションは レイテンシー スループット要件 ジッター および帯域幅に応じて異なります ロケーションのオプションは ユーザーまたはオンプレミスのリソースなどの物理的な制約に左右されます これらの制約は エッジロケーションまたはリソースの配置で相殺することができます … ネットワークとコンテンツ配信 プロセスと文化 ワークロードのパフォーマンス効率を高めるために、どのようなプロセスを使用していますか? PERF 5 ワークロードを設計する際には 効率的で高性能なクラウドワークロードをより良く実行するために採用できる原則と慣行があります … プロセスと文化 システムの要件を満たすためにコンピューティングリソースを効率的に使用し、要求の変化とテクノロジーの進化に対してもその効率性を維持する能力です。 パフォーマンス効率 サービスクォータと制約 サービスクォータと制約はどのように管理しますか? REL 1 ネットワークトポロジ ネットワークトポロジをどのように計画しますか? REL 2 基盤となる要件は 単一のワークロードまたはプロジェクトの範囲を超える要件です システムを設計する前に 信頼性に影響を与える基本的な要件を満たしておく必要があります 例えば データセンターへの十分なネットワーク帯域幅が必要です … 基盤 サービスアーキテクチャ どのようにワークロードサービスアーキテクチャを設計すればよいですか? REL 3 障害を防ぐための操作を設計する 障害を防ぐために、分散システムの操作をどのように設計しますか? REL 4 障害を軽減するための操作を設計する 障害を緩和または耐えるために、分散システムの操作をどのように設計しますか? REL 5 信頼性の高いワークロードは ソフトウェアとインフラストラクチャの両方について事前に設計を決定することから始まります アーキテクチャの選択は 5 つの Well Architected の柱すべてにかけてワークロードの動作に影響を与えます 高い信頼性を保つには 特定のパターンに従う必要があります … ワークロードアーキテクチャ リソースのモニタリング ワークロードリソースをモニタリングするにはどうすればよいですか? REL 6 需要の処理 需要の変化に適応するようにワークロードを設計するには、どうすればよいですか? REL 7 変更管理 変更はどのように実装するのですか? REL 8 ワークロードを信頼できる形で運用するには ワークロードやその環境に対する変化を予測してそれに対応することが不可欠です 変更には 需要の急増といったワークロードに強いられる変更や 機能のデプロイやセキュリティパッチの適用といった内部からの変更があります … 変更管理 データバックアップ データはどのようにバックアップするのですか? REL 9 障害分離 ワークロードを保護するために障害分離をどのように使用しますか? REL 10 弾力性のある設計 コンポーネントの障害に耐えるようにワークロードを設計するにはどうすればよいですか? REL 11 信頼性テスト どのように信頼性をテストしますか? REL 12 災害対策 災害対策 (DR) はどのように計画するのですか? REL 13 ある程度複雑なシステムでは 障害が発生することが予想されます ワークロードで信頼性を確保するには 発生時点で障害を認識し 可用性への影響を回避するための措置を講じることが必要です ワークロードは 障害に耐え 問題を自動的に修復できる必要があります … 障害管理 期待される時に意図された機能を正しく一貫して実行するワークロードの能力を含みます。これには、ワークロードのライフサイクル全体を通じてワークロードを運用およびテストする能力が含まれます。このホワイトペーパーでは、AWS で信頼性の高いワークロードを実装するための詳しいベストプラクティスガイダンスを提供します。 信頼性 オペレーションの優先順位 優先順位はどのように決定すればよいでしょうか? OPS 1 運用モデル ビジネスの成果をサポートするために、組織をどのように構築しますか? OPS 2 組織カルチャー 組織の文化はビジネスの成果をどのようにサポートしますか? OPS 3  チームは ビジネスの成功を実現する優先順位を設定するために ワークロード全体 その役割 共有されるビジネス目標に関する理解を共有する必要があります 優先順位を明確に定義することで 努力を通じて得られるメリットが最大限に活かされます ビジネス 開発 運用チームなど 主要な利害関係者が関わる社内外の顧客のニーズを評価し 重点領域を決定します 顧客ニーズを評価することにより ビジネス成果を達成するために必要なサポートについて十分に理解できるようになります 組織のガバナンスによって定義されたガイドラインや義務 および特定の重点領域の必須化や重視が必要となる可能性のある規制コンプライアンス要件や業界標準などの外部要因をしっかりと認識します 内部ガバナンスおよび外部コンプライアンス要件への変更を識別するメカニズムがあることを検証します 要件が特定されていない場合は 必ずこの決定にデューデリジェンスが適用されていることを確認します ニーズの変化に応じて更新できるように 優先順位を定期的に確認します ビジネスに対する脅威 たとえば ビジネスリスクと負債や情報セキュリティの脅威 を評価し この情報をリスクレジストリに保持します リスクの影響を評価し 競合する利益のトレードオフや代替アプローチを評価します たとえば 新しい機能の市場投入までの時間を短縮することは コストの最適化よりも重視されます または 非リレーショナルデータ用にリレーショナルデータベースを選択すれば リファクタリングなしで システムの移行が簡素化されます メリットとリスクを管理し 重点領域を決定する際に十分な情報に基づいて意思決定を下せるようにします 一部のリスクや選択肢は 一定期間許容される可能性があり 関連するリスクを軽減できる場合もあれば リスクが残るのを容認できない場合もあります その場合 リスクに対処するための措置を講じることになります チームはビジネスの成果を達成するうえでの役割を理解する必要があります チームは他のチームが成功するためのそれぞれの役割を理解し 自分たちのチームが成功するための他のチームの役割を理解し 目標を共有する必要があります 責任 所有権 意思決定方法 意思決定を行う権限を持つユーザーを理解することは 労力を集中的に投入し チームの利点を最大化するのに役立ちます チームのニーズは サポートする顧客 組織 チームの構成 およびワークロードの特性によって形成されます 1 つの運用モデルによって 組織内のすべてのチームとそのワークロードをサポートできると期待するのは合理的ではありません アプリケーション ワークロード プラットフォーム インフラストラクチャの各コンポーネントの所有者が特定されていること および各プロセスと手順の定義を担当する所有者 およびそのパフォーマンスに責任を持つ所有者が特定されていることを確認します 各コンポーネント プロセス 手順のビジネス価値 それらのリソースが配置されている理由やアクティビティが実行されている理由 所有権が存在する理由を理解することで チームメンバーのアクションが明らかになります チームメンバーの責任を明確に定義することで 当該メンバーが適切に行動し 責任と所有権を識別するメカニズムを持つことができます イノベーションを制約しないように 追加 変更 例外をリクエストするメカニズムを備えます チームがどのように連携して相互にサポートするのか また ビジネスの成果について チーム間の合意を定義します チームメンバーにサポートを提供することで チームメンバーがより効果的に行動し ビジネスの成果をサポートできるようにします 業務を委嘱された上級リーダーは 目標値を設定し 成功を測定する必要があります 上級リーダーは ベストプラクティスの採用と組織の進化の協賛者 支持者 および推進者である必要があります 影響を最小限に抑えるために 結果にリスクがある場合は措置を講じるようにチームメンバーの意識を高めるとともに リスクに対処し インシデントを回避できるようにするため リスクがあるとチームメンバーが考える場合は 意思決定者や利害関係者にエスカレーションすることを推奨します チームメンバーがタイムリーで適切な措置を講じることができるように 既知のリスクと計画されたイベントについて 適時かつ明確で実用的なコミュニケーションを行います 学習を加速するための実験を奨励し チームメンバーが関心と当事者意識を持ち続けるようにします チームは 新しいテクノロジーを採用し 需要と責任の変化をサポートするために スキルセットを強化する必要があります 学習に専念するために設定された時間を提供することで これをサポートし 奨励します チームメンバーが成功し ビジネスの成果をサポートするためにスケールできるように ツールとチームメンバーの両方のリソースを持っていることを確認します 組織間の多様性を活用して 複数のユニークな視点を追求します この視点を使用して イノベーションを高め 想定に挑み 確証バイアスに傾くリスクを軽減します チーム内のインクルージョン 多様性 アクセシビリティを向上させ 有益な視点を得ます … 組織 オブザーバビリティを実装する オブザーバビリティをワークロードに実装するにはどうすればよいでしょうか? OPS 4 開発と統合 どのように欠陥を減らし、修正を容易にして、本番環境へのフローを改善するのですか? OPS 5 デプロイのリスクの軽減 どのようにデプロイのリスクを軽減しますか? OPS 6 運用準備状況 ワークロードをサポートする準備が整っていることはどうすれば確認できるでしょうか? OPS 7  運用上の優秀性を準備するには ワークロードと期待される動作を理解する必要があります そうすることでワークロードの状況を把握し ワークロードをサポートする手順を構築するように設計できます ワークロードを設計する際には 可観測性と問題調査への対応においてすべてのコンポーネントにわたって内部状態 メトリクス ログ イベント トレースなど を理解するために必要な情報が送出されるようにします ワークロードの稼働状態を監視し 結果にリスクがあった場合にそれを特定し 効果的な対応を可能にするために必要なテレメトリの開発を繰り返します ワークロードを計測する際は フィルターを使用して時間の経過とともに最も有用な情報を選択できるので 状況認識を可能にする幅広い情報 状態の変化 ユーザーのアクティビティ 権限アクセス 使用量のカウンターなど を取得します リファクタリング 品質についてのすばやいフィードバック バグ修正を可能にし 本番環境への変更のフローを改善するアプローチを採用します これらは 本番環境移行時における有益な変更を促進し デプロイされた問題を制限するとともに お客様の環境において デプロイメントアクティビティを通じて生じた問題 または検出された問題をすばやく特定し 修正できるようにします 品質に関する迅速なフィードバックを提供し 望ましい結果をもたらさない変更から迅速に復旧できるようにするアプローチを採用します これらを実践することにより 変更のデプロイメントによって生じる問題の影響が軽減されます 変更が失敗した場合の計画を立てて 必要な場合は迅速に対応し 変更をテストして検証できるようにします 環境で計画されたアクティビティに注意して 計画されたアクティビティに影響する変更のリスクを管理できるようにします 頻繁で小さく可逆的な変更に重点を置いて 変更の範囲を制限します これにより トラブルシューティングが容易になり 修復がすばやくできるようになります また 変更をロールバックすることもできます また より頻繁に重要な変更の恩恵を受けることができることを意味します ワークロード プロセス 手順 および従業員の運用準備状況を評価し ワークロードに関連する運用上のリスクを理解します 一貫性のあるプロセス 手作業または自動化によるチェックリストを含む を使用して いつワークロードまたは変更を本稼働する準備ができるかを知る必要があります また これにより 対処する計画を立てる必要がある領域を見つけることもできます 日常的な活動を文書化したランブックと 問題解決のためにプロセスを導くプレイブックを備えます メリットとリスクを理解し 十分な情報に基づく決定を下して 変更が本稼働環境に入ることを可能にします … 準備 ワークロードのオブザーバビリティ 組織でワークロードのオブザーバビリティを活用するにはどうすればよいでしょうか? OPS 8 運用の正常性 オペレーションの正常性をどのように把握しますか? OPS 9 イベントへの対応 ワークロードと運用イベントはどのように管理しますか? OPS 10  ワークロードの運用の成功は ビジネスの成果と顧客の成果の達成度によって評価されます 予想される成果を定義し 成功を評価する方法を決定します また ワークロードおよび運用が成功したかどうかを判断するための計算で使用するメトリクスを特定します 運用状態には ワークロードの状態と そのワークロードのサポートにおいて実行されるオペレーション活動の状態と成功 デプロイとインシデント対応など の両方を含みます 改善 調査 介入のためのメトリクスのベースラインを確立し メトリクスを収集して分析し オペレーションの成功と経時的な変化について理解していることを検証します 収集したメトリクスを使用して 顧客とビジネスのニーズを満たしているかどうかを確認し 改善の余地がある分野を特定します 運用上の優秀性を実現するには 運用上のイベントを効率的かつ効果的に管理する必要があります 計画的および予期しない運用イベントの両方に適用されます 十分に把握しているイベントには既定のランブックを使用し 問題の調査および解決にはプレイブックを使用します ビジネスと顧客への影響に基づいてイベントへの応答に優先順位を付けます イベントへの応答でアラートが発生する場合 実行する関連プロセスがあり 所有者が具体的に指名されていることを確認します イベントを解決する担当者を事前に決めておき 緊急性および影響に基づき 必要に応じて他の担当者を関与させるためにエスカレーションするトリガーを含めます 以前に処理したことがないイベント応答によってビジネスに影響が及ぶ場合は アクションの方針を決定する権限を持つ担当者を特定し 関与させます 対象 顧客 ビジネス 開発者 運用など に合わせたダッシュボードと通知によってワークロードの運用状況が伝えられるため 適切なアクションの実行や予測の管理 通常の運用が再開される時期の把握を行うことができます … 運用 オペレーションの進化 オペレーションを進化させる方法 OPS 11  運用上の優秀性を維持するには 学び 共有し 継続的に改善する必要があります 継続的かつ段階的な改善を行うために専用の作業サイクルを作成します 顧客に影響を与えるすべてのイベントについて インシデント後の分析を実行します 反復を制限または防止する要因と予防措置を特定します 必要に応じて 影響を受けたコミュニティと貢献要因を伝達します ワークロードと運用手順の両方について 改善の機会 機能のリクエスト 問題の修正 コンプライアンス要件など を定期的に評価し 優先順位を付けます 手順にフィードバックループを取り入れ 改善が必要な分野をすばやく特定し 実際に運用して教訓を学びます チーム間で学んだ教訓を共有し その教訓の利点を活用します 学んだ教訓に見られる傾向を分析し 運用のメトリクスに関してチーム間で遡及的分析を行い 改善の機会とその方法を特定します 改善をもたらす変更を実施し 結果を評価して成功の判断を行います … 進化 開発をサポートし、ワークロードを効率的に実行し、運用に関する洞察を得て、ビジネス価値をもたらすためのサポートプロセスと手順を継続的に改善する能力。 運用上の優秀性 運用のセキュリティを確保する ワークロードを安全に運用するには、どうすればよいですか? SEC 1 ワークロードを安全に運用するには セキュリティのすべての領域に包括的なベストプラクティスを適用する必要があります 組織レベルおよびワークロードレベルにおいて 運用上の優秀性で定義した要件とプロセスを抽出し それらをすべての領域に適用します … セキュリティ 認証 ユーザー ID とマシン ID はどのように管理したらよいでしょうか? SEC 2 認証とアクセスコントロール 人とマシンのアクセス許可はどのように管理すればよいでしょうか? SEC 3 アイデンティティとアクセスの管理は情報セキュリティプログラムの重要な要素です これにより お客様が意図した方法で承認 認証されたユーザーおよびコンポーネントのみがリソースにアクセスできるようになります たとえば プリンシパル つまり お客様のアカウントに対してアクションをとるアカウント ユーザー ロール サービス を定義し これらのプリンシパルに合わせたポリシーを構築し 強力な認証情報管理を実装できます これらの権限管理機能は認証と承認の中枢となっています … Identity & Access Management セキュリティイベント セキュリティイベントをどのように検出し、調査していますか？ SEC 4 発見的統制により セキュリティの潜在的な脅威やインシデントを特定できます これはガバナンスフレームワークの最重要機能であり 品質管理プロセス 法的義務またはコンプライアンス義務 脅威の特定とその対応のサポートのために この機能を使用できます さまざまな種類の発見的統制があります 例えば アセットとそれらの詳細な属性のインベントリを実行することで より効果的に意思決定やライフサイクル管理を行い 運用の基準を確立できます また 内部監査という 情報システムに関連するコントロールの検査を行って ポリシーと要件に準拠し 定義した条件に基づいて正確に自動化されたアラート通知を設定できます これらのコントロールは 組織が異常なアクティビティの範囲を特定し把握するのに役立つ重要な対応機能です … 検知 ネットワーク保護 ネットワークリソースをどのように保護しますか? SEC 5 コンピューティング保護 コンピューティングリソースをどのように保護していますか? SEC 6 インフラストラクチャ保護には ベストプラクティスと組織の義務または規制上の義務に準拠するために必要な 深層防御などの制御手段が含まれています これらの手段を用いることは クラウドやオンプレミスの環境で滞りなく運用していくために特に重要です … インフラストラクチャ保護 データ分類 どのようにデータを分類していますか? SEC 7 保管中のデータの保護 保管時のデータをどのように保護していますか? SEC 8 伝送中のデータの保護 転送時のデータをどのように保護していますか? SEC 9 システムを設計する前に セキュリティに影響を与える基本的なプラクティスを実施する必要があります 例えば データ分類は組織のデータを機密性レベルに基づいてカテゴリーに分類し 暗号化は認証されていないアクセスに対してデータが開示されてしまうことを防ぎます これらのツールやテクニックは 金銭的な損失の予防や規制遵守という目的を達成するためにも重要です … データ保護 インシデント対応 インシデントの予測、対応、復旧はどのように行いますか? SEC 10 成熟した予防的 発見的統制が実装されていても 組織はセキュリティインシデントの潜在的な影響に対応し 影響を緩和するメカニズムを実装する必要があります 準備することで インシデントの際にチームが効果的に動作し 問題を切り分け 封じ込め フォレンジックを実行し 運用を既知の正常な状態に復元する能力に強く影響します セキュリティインシデントが起こる前にツールとアクセス権を整備し ゲームデー 実践訓練 を通じてインシデント対応を定期的に実施しておけば ビジネスの中断を最小限に抑えながら復旧することができます … インシデント対応 アプリケーションのセキュリティ 設計、開発、デプロイのライフサイクル全体を通じて、アプリケーションのセキュリティ特性をどのように組み込み、検証すればよいのでしょうか? SEC 11 アプリケーションのセキュリティ AppSec は 開発するワークロードのセキュリティ特性の設計 構築 テストの各方法の全体的なプロセスを説明するものです 適切なトレーニングを受けた人材を組織に配置した上で ビルドのセキュリティ特性を理解してインフラストラクチャをリリースし 自動化を使用してセキュリティの問題を識別する必要があります ソフトウェア開発ライフサイクル SDLC とリリース後プロセスの一部としてアプリケーションセキュリティテストを採用することで 本稼働環境でのアプリケーションのセキュリティ問題の識別 修正 防止のための構造的なメカニズムを確立することができます ワークロードを設計 構築 デプロイ 運用する際 アプリケーション開発手法にはセキュリティコントロールを含める必要があります その中で 継続的な欠陥削減のプロセスと技術的負債の低減を調整します 例えば 脅威モデリングを設計フェーズで使用すると 設計上の欠陥を早期に発見することができ 後になって問題を軽減するのと比較して 欠陥の修正をより簡単に より安価に行うことができます 一般的に SDLC の早期に欠陥を解決することで コストと複雑性を抑えられます 最も簡単な問題解決の方法は そもそも問題を抱えないことです したがって 最初に脅威モデルを作成することで 設計フェーズから適切な成果にフォーカスすることができます AppSec プログラムが成熟するにつれて 自動化を使ってテストの数を増やしたり ビルダーへのフィードバックの忠実性を高めたり セキュリティレビューに必要な時間を短縮したりすることができます これらすべてのアクションは 構築するソフトウェアの品質を改善し 本稼働への機能の実装までの時間を短縮します これらの実装ガイドラインは 組織と文化 パイプラインのセキュリティ パイプラインでのセキュリティ および依存関係管理の 4 つの領域にフォーカスしています 各領域は 実装可能な一連の原則と ワークロードの設計 開発 構築 デプロイ 運用のエンドツーエンドビューを提供します … アプリケーションのセキュリティ データ、システム、および資産を保護して、セキュリティを強化するためにクラウドテクノロジーを活用する能力。 セキュリティ