Update cloud-native-security-whitepaper-ja.md (#1455)

Signed-off-by: Yoshiyuki Tabata <34849594+y-tabata@users.noreply.github.com>

Author: y-tabata

community/resources/security-whitepaper/v2/cloud-native-security-whitepaper-ja.md

@@ -44,7 +44,7 @@
 
 #### デプロイ
 
-開発と配布の段階を通じて統合されたセキュリティは、ワークロードの属性をリアルタイムかつ継続的に検証することができます。例えば、署名された成果物の検証、コンテナイメージとランタイムのセキュリティポリシーの確保、ホストの適合性と信頼性は、ステージング環境と本番環境のバイナリ認証ポリシーによって検証することができます。デプロイ時のチェックは、意図したビジネスニーズに応えるワークロードを実行する前に、検証や修正を実施する最後の機会を提供します。ワークロードと一緒に展開されるセキュアなワークロード監視機能により、ログや利用可能なメトリクスを高い信頼性で監視することができ、統合セキュリティを補完することができます。
+開発と配布の段階を通じて統合されたセキュリティは、ワークロードの属性をリアルタイムかつ継続的に検証することができます。例えば、署名された成果物の検証、コンテナイメージとランタイムのセキュリティポリシーの確保、ホストの適合性と信頼性は、ステージング環境と本番環境のバイナリ認可ポリシーによって検証することができます。デプロイ時のチェックは、意図したビジネスニーズに応えるワークロードを実行する前に、検証や修正を実施する最後の機会を提供します。ワークロードと一緒に展開されるセキュアなワークロード監視機能により、ログや利用可能なメトリクスを高い信頼性で監視することができ、統合セキュリティを補完することができます。
 
 #### ランタイム
 
@@ -221,7 +221,7 @@ IaCは、組織がクラウドやコンテナインフラを展開するため
 
 コンテナイメージの暗号化は、コンテナイメージを暗号化しその内容を機密にします。コンテナイメージのコンテンツは、ビルド時からランタイムまで昇格しても機密性を保つように暗号化されます。配布物が漏洩した場合でも、イメージのレジストリ内容は秘匿されるため、企業秘密や機密資料の保護などのユースケースに役立ちます。
 
-コンテナイメージの暗号化のもう一つの用途は、コンテナイメージの認可を強制することです。イメージの暗号化が、鍵管理とランタイム環境の認証、および/または認証とクレデンシャルの配布と連動している場合、コンテナイメージが特定のプラットフォーム上でのみ実行できることを要求することができます。コンテナイメージの認可は、ジオフェンシングや輸出管理、デジタル著作権メディア管理などのコンプライアンスユースケースに有効です。
+コンテナイメージの暗号化のもう一つの用途は、コンテナイメージの認可を強制することです。イメージの暗号化が、鍵管理とランタイム環境の認証、および/または認可とクレデンシャルの配布と連動している場合、コンテナイメージが特定のプラットフォーム上でのみ実行できることを要求することができます。コンテナイメージの認可は、ジオフェンシングや輸出管理、デジタル著作権メディア管理などのコンプライアンスユースケースに有効です。
 
 ### デプロイ
 
@@ -431,7 +431,7 @@ _図5_
 
 アプリケーションやサービスのアイデンティティは、マイクロサービスのコンテキストでも必要不可欠であることに特に注意してください。アプリのアイデンティティが悪意のあるサービスによってなりすましや偽造される可能性があります。強力なアイデンティティフレームワークとサービスメッシュを活用することで、これらの問題を克服することができます。
 
-すべての人間および非人間の、クラスターやワークロードオペレータは認証されなければならず、そのすべてのアクションは、各リクエストのコンテキスト、目的、および出力を評価するアクセス制御ポリシーに照らして評価する必要があります。認証プロセスを簡素化するために、アイデンティティフェデレーションは、多要素認証のようなエンタープライズ機能の使用を許可するように構成することができます。認証は、このセクションで述べたアクセス制御メカニズムで実施されなければなりません。
+すべての人間および非人間の、クラスターやワークロードオペレータは認証されなければならず、そのすべてのアクションは、各リクエストのコンテキスト、目的、および出力を評価するアクセス制御ポリシーに照らして評価する必要があります。認証プロセスを簡素化するために、アイデンティティフェデレーションは、多要素認証のようなエンタープライズ機能の使用を許可するように構成することができます。認可は、このセクションで述べたアクセス制御メカニズムで実施されなければなりません。
 
 ##### クレデンシャルの管理
 
@@ -639,7 +639,7 @@ DevOps環境でしばしば発生する境界線の曖昧さは、クラウド
 
 効果的なサプライチェーン戦略は、ファーストおよびサードパーティのソフトウェア作成者、インテグレーター、ディストリビューターに関連するリスクを軽減するための成熟したポリシーと手順に依存しています。各当事者は、関連情報を正確かつ効果的に伝達しなければなりません。サプライチェーンポリシーには、欠陥のあるサプライチェーンからの被害を制限するように設計されたコントロールを持つ多様なプロバイダを含めるべきです。システムやソフトウェア、コンフィギュレーションの出自を追跡できる機能と、成果物とそれを生み出した連鎖の両方の起源を追跡し完全性を検証する機能を提供します。
 
-ソフトウェアのサプライチェーンは、ソースコード、セカンドまたはサードパーティのコード、ビルドパイプライン、成果物、デプロイメントで構成されます。これらの各段階は、暗号的に検証でき、可能であれば自動化できるような、認証された信頼される当事者によって実行されなければなりません。すべての信頼されるエンティティは、漏洩の影響を低減するために、認証範囲を限定すべきです。
+ソフトウェアのサプライチェーンは、ソースコード、セカンドまたはサードパーティのコード、ビルドパイプライン、成果物、デプロイメントで構成されます。これらの各段階は、暗号的に検証でき、可能であれば自動化できるような、認証された信頼される当事者によって実行されなければなりません。すべての信頼されるエンティティは、漏洩の影響を低減するために、認可範囲を限定すべきです。
 
 ソフトウェア部品表(SBOM)は、どのようなソフトウェア部品があるかを発見するための重要な第一歩であり、それによって既知の脆弱性と関連付けることができます。SBOMは、ソースコードからビルド時に SPDXやCyclone DX、SWID などの標準化されたフォーマットを使用して生成されるべきであり、インポートされたライブラリやツールのSBOMにリンクされるべきです。SBOMに含まれるソースコードとコンポーネントのメタデータは、ソフトウェアサプライチェーンの改ざんを特定するために開発者や運用者が使用することもできます。CI/CDシステムは、SBOMで再現された署名でアプリケーションとコンテナイメージの両方に署名すべきです。運用者は、バイナリまたはイメージからビルド後のSBOM生成ツールを使用して、ビルド時のSBOMの正確性を検証することができます。ソフトウェアの作成者および供給者が使用するプロセスを検証するために、エンドツーエンドの証明書を使用することができます。これらの証明は、ソフトウェアサプライチェーンの各段階に追加する必要があります。
 
@@ -1074,4 +1074,4 @@ RV.3.2
 #### 謝辞
 <!-- cspell:disable -->
 この白書は、CNCFセキュリティTAGのメンバーによって推進されたコミュニティの取り組みです。優れた貢献をしてくれた皆さんに感謝します。特にEmily FoxとJeyappragash JJに感謝します。
-<!-- cspell:enable -->
+<!-- cspell:enable -->