Share your requirements and we'll get back to you with how we can help.
組織の事業運営を活発にするクラウドコンピューティング、モビリティ、IoTなどの技術は、新たなセキュリティ課題に対する組織の脆弱性を高めます。総合的なリスク管理にはまず自社のセキュリティ態勢の理解を深め、効果的な管理対策を敷くことから始まります。
最初のステップでは、組織における保護の必要なデータや重要リソース全ての評価を行います。インターネットへの露出はそれ自体がリスクをもたらしますが、事業運営において必須であるのも事実です。だからこそ、それぞれのリソースがどれだけのリスクを許容できるか、を評価することが重要となってくるのです。同様に保護レベルによってコストが左右されることを考慮すると、適切なレベルのリスク軽減システムを導入することが必要とわかります。
何をどう保護するかを特定ができたら、評価の次の段階にあたるサイバーセキュリティの枠組みの構築へ進んでいきます。この枠組みはサイバーセキュリティ関連の基準、方針、プロセスで構成され、組織のセキュリティ関連の運用を規制する役割を担います。
前項のサイバーセキュリティの枠組みはシステム内の変化に係るリスク評価を促進させ、様々な既知、未知の脅威に備える一助となります。当社ではお客様の組織の運用の成熟度を評価するほか、侵入テストといったプロアクティブ試験を実施して準備体制を確認します。
システムを攻撃から完全に守るのは不可能です。それでも多層の防御策を張ることで、重要なITインフラやデータに攻撃ベクトルが侵入するのを遅らせる、もしくは困難にさせることができます。
システム内の各コンポーネントには最低限レベルのアクセス権が提供されます。アクセス要求を明確化することで、アクセス権限の定義付けを可能にします。
*This is a general model. Practices are adapted according to the environment.
システムを攻撃から完全に守るのは不可能です。それでも多層の防御策を張ることで、重要なITインフラやデータに攻撃ベクトルが侵入するのを遅らせる、もしくは困難にさせることができます。
システム内の各コンポーネントには最低限レベルのアクセス権が提供されます。アクセス要求を明確化することで、アクセス権限の定義付けを可能にします。
コンテナは企業アプリケーションにおける重要な一部となりつつあります。コンテナはイミュータブル・インフラストラクチャーを構築するのに役立ちます。イミュータブルなシステムの構築で攻撃ベクトルがコンテナにアクセスし、バックドアを仕込むために変更を加えることを困難にします。さらにはコンテナのアップデートも容易にします。万一コンテナにセキュリティの脆弱性が確認された場合、交換可能であるため脅威をそのコンテナに限定することができます。
コンテナは最小限のソフトウェアコンポーネントで構成されるため、攻撃対象領域を減らすことができます。また各コンテナのエントリ・イグジットポイントも明確に定義付けられています。最小権限の法則に則り、コンテナの複数リソースへのアクセス権を機能するために必要最低限のもののみ制限することができます。
コンテナは企業アプリケーションにおける重要な一部となりつつあります。コンテナはイミュータブル・インフラストラクチャーを構築するのに役立ちます。イミュータブルなシステムの構築で攻撃ベクトルがコンテナにアクセスし、バックドアを仕込むために変更を加えることを困難にします。さらにはコンテナのアップデートも容易にします。万一コンテナにセキュリティの脆弱性が確認された場合、交換可能であるため脅威をそのコンテナに限定することができます。
コンテナは最小限のソフトウェアコンポーネントで構成されるため、攻撃対象領域を減らすことができます。また各コンテナのエントリ・イグジットポイントも明確に定義付けられています。最小権限の法則に則り、コンテナの複数リソースへのアクセス権を機能するために必要最低限のもののみ制限することができます。
ただし、コンテナのセキュリティは下記の対策によって効果が左右されます。
コンテナをrootとして実行する:rootユーザとして実行されるコンテナは、root権限を持つどんなアプリケーションと同等に脆弱です。組織でコンテナ化されたアプリケーションを展開する場合、コンテナ技術は信頼境界線を作らない、ということに注意しなければいけません。その場合にはシステム内の特定ユーザやグループでコンテナを実行してください。
イメージの出所:いかなるアプリケーションも、それを構築するイメージと同等のセキュリティレベルしか持てません。よってコンテナベースのインフラの安全を守るには、イメージ識別と信頼メカニズムが非常に重要となります。この際には証明書や電子署名を用いるプライベートの認証リポジトリがあると便利です。信頼できるイメージのリポジトリは暗号化され、セキュリティプロセスの遵守を確実にするためリポジトリは監査の対象です。
セキュリティテスト: すべてのイメージは本番環境の展開前にセキュリティテストを行う必要があります。セキュリティテストはCI/CDパイプラインの一部でありつつ、ユニットテストと同様に実行されるのが理想です。そして、構築されたイメージがセキュリティテストに合格して初めて、パイプラインがスタックにコンテナを展開します。
コンテナ VS 仮想マシン:セキュリティの観点から
コンテナは仮想マシンほどの隔離性を持ちません。仮想マシンでは、ゲストのオペレーティングシステム同士でカーネルを共有することは一切なく、システムごとに異なるセキュリティプロファイルを持つことができます。別システムに影響を及ぼす可能性はほとんどありません。他方コンテナは、ホストとセキュリティプロファイルを共有するアプリケーション同士を隔離する強力な手段を持っています。
コンテナはこのアプリケーションの隔離を確実に行うため、Linuxカーネルが提供するプロセス隔離のための機能を利用します。しかしプロセスの多くの面で(ユーザ名の入力スペース等)Linuxのカーネルでは隔離されていません。これによりコンテナ隔離のメカニズムは脆弱な攻撃対象領域と化してしまいます。よってコンテナにアクセスした攻撃者はコンテナの実行時間を悪用し、他のコンテナやホストに悪影響を及ぼすことを可能にしてしまうのです。
を用いれば、アプリケーションのネットワークポートやファイルデバイスといった他のリソース上での操作におけるアクセスや実行能力を制御することが強制アクセス制御できます。コンテナの例で言うと、アクセス制御を行うことでコンテナがホストや他のコンテナに影響を与える能力を制限することが可能になります。
MACシステム SELinuxまたはAppArmorのいずれかで適切なポリシーを策定することで、攻撃者がコンテナで提供されるサービスを悪用したとしても攻撃を封じ込めることが可能になります。当社ではお客様が必要とするセキュリティ・柔軟性のレベルに応じて適切なMACツールを選択するお手伝いをいたします。またMACの代わりにLinuxカーネルを使い、コンテナアプリケーションに制限をかけることもできます。
インターネットに接続されたすべてのアプリケーションやサービスに対してセキュリティの第一段階を提供するのがファイアウォールです。クラウドインフラの出現により、仮想プライベートクラウド(VPC)といったセキュリティ強化のための追加的機構が利用できるようになりました。VPCを用いた仮想プライベートネットワークを介することで、インターネット上に露出するノードを一定数に限定し一連のコンピューティングリソースを作成することが可能になります。これらノード間にネットワークルールを設定することでセキュリティ侵害を防ぐことができます。多くの場合外部からのネットワークアクセスに焦点が置かれますが、それぞれのコンピューティングリソースから送信されるトラフィックを制限することも同様に重要であり有用です。
仮想マシンとコンテナにおいて、ホストのセキュリティもまた懸念事項の一つです。ホストプラットフォームやランタイムの脆弱性はコンテナ全体に及ぶセキュリティ侵害を誘発する恐れがあります。いずれの場合もフルロードのシステムを使うことは攻撃対象領域を広げてしまう可能性があります。
仮想マシンやコンテナが持つ隔離性はベアメタルサーバのそれと同程度ではありません。Google提供のgVisorといった技術を使えば、セキュリティ層をさらに追加することが可能です。以上すべてから、セキュリティ戦略の策定は慎重に行う必要があることを示しています。
マシン間の全通信はトランスポート・レイヤー・セキュリティ(TLS)プロトコルをもって安全に行うことが推奨されます。通信をするにあたり、可能な限りプライベートIPを介して行われるべきです。保存データはAES-256を用いて暗号化し、適切なデータ管理対策を実施しましょう。これは組織のプライバシーポリシー遵守及び契約上の義務履行に大いに役立ちます。
マイクロサービス型のアプリケーション展開の台頭に伴い、APIキーはリスクの源となっています。これらAPIキーを安全ではない形で使用しているケースがしばしば見られます。一旦サービスが侵害されると、そのサービスが別サービスで使用するキーも攻撃者に盗まれ、五月雨式に侵害が発生する恐れがあります。APIキーを持つデプロイスクリプトがバージョン管理システム上で暴露される例は非常に頻繁に見られます。
コンテナは企業アプリケーションにおける重要な一部となりつつあります。コンテナはイミュータブル・インフラストラクチャーを構築するのに役立ちます。イミュータブルなシステムの構築で攻撃ベクトルがコンテナにアクセスし、バックドアを仕込むために変更を加えることを困難にします。さらにはコンテナのアップデートも容易にします。万一コンテナにセキュリティの脆弱性が確認された場合、交換可能であるため脅威をそのコンテナに限定することができます。
コンテナは最小限のソフトウェアコンポーネントで構成されるため、攻撃対象領域を減らすことができます。また各コンテナのエントリ・イグジットポイントも明確に定義付けられています。最小権限の法則に則り、コンテナの複数リソースへのアクセス権を機能するために必要最低限のもののみ制限することができます。
ただし、コンテナのセキュリティは下記の対策によって効果が左右されます。
コンテナをrootとして実行する:rootユーザとして実行されるコンテナは、root権限を持つどんなアプリケーションと同等に脆弱です。組織でコンテナ化されたアプリケーションを展開する場合、コンテナ技術は信頼境界線を作らない、ということに注意しなければいけません。その場合にはシステム内の特定ユーザやグループでコンテナを実行してください。
イメージの出所:いかなるアプリケーションも、それを構築するイメージと同等のセキュリティレベルしか持てません。よってコンテナベースのインフラの安全を守るには、イメージ識別と信頼メカニズムが非常に重要となります。この際には証明書や電子署名を用いるプライベートの認証リポジトリがあると便利です。信頼できるイメージのリポジトリは暗号化され、セキュリティプロセスの遵守を確実にするためリポジトリは監査の対象です。
セキュリティテスト: すべてのイメージは本番環境の展開前にセキュリティテストを行う必要があります。セキュリティテストはCI/CDパイプラインの一部でありつつ、ユニットテストと同様に実行されるのが理想です。そして、構築されたイメージがセキュリティテストに合格して初めて、パイプラインがスタックにコンテナを展開します。
コンテナ VS 仮想マシン:セキュリティの観点から
コンテナは仮想マシンほどの隔離性を持ちません。仮想マシンでは、ゲストのオペレーティングシステム同士でカーネルを共有することは一切なく、システムごとに異なるセキュリティプロファイルを持つことができます。別システムに影響を及ぼす可能性はほとんどありません。他方コンテナは、ホストとセキュリティプロファイルを共有するアプリケーション同士を隔離する強力な手段を持っています。
コンテナはこのアプリケーションの隔離を確実に行うため、Linuxカーネルが提供するプロセス隔離のための機能を利用します。しかしプロセスの多くの面で(ユーザ名の入力スペース等)Linuxのカーネルでは隔離されていません。これによりコンテナ隔離のメカニズムは脆弱な攻撃対象領域と化してしまいます。よってコンテナにアクセスした攻撃者はコンテナの実行時間を悪用し、他のコンテナやホストに悪影響を及ぼすことを可能にしてしまうのです。
を用いれば、アプリケーションのネットワークポートやファイルデバイスといった他のリソース上での操作におけるアクセスや実行能力を制御することが強制アクセス制御できます。コンテナの例で言うと、アクセス制御を行うことでコンテナがホストや他のコンテナに影響を与える能力を制限することが可能になります。
MACシステム SELinuxまたはAppArmorのいずれかで適切なポリシーを策定することで、攻撃者がコンテナで提供されるサービスを悪用したとしても攻撃を封じ込めることが可能になります。当社ではお客様が必要とするセキュリティ・柔軟性のレベルに応じて適切なMACツールを選択するお手伝いをいたします。またMACの代わりにLinuxカーネルを使い、コンテナアプリケーションに制限をかけることもできます。
インターネットに接続されたすべてのアプリケーションやサービスに対してセキュリティの第一段階を提供するのがファイアウォールです。クラウドインフラの出現により、仮想プライベートクラウド(VPC)といったセキュリティ強化のための追加的機構が利用できるようになりました。VPCを用いた仮想プライベートネットワークを介することで、インターネット上に露出するノードを一定数に限定し一連のコンピューティングリソースを作成することが可能になります。これらノード間にネットワークルールを設定することでセキュリティ侵害を防ぐことができます。多くの場合外部からのネットワークアクセスに焦点が置かれますが、それぞれのコンピューティングリソースから送信されるトラフィックを制限することも同様に重要であり有用です。
仮想マシンとコンテナにおいて、ホストのセキュリティもまた懸念事項の一つです。ホストプラットフォームやランタイムの脆弱性はコンテナ全体に及ぶセキュリティ侵害を誘発する恐れがあります。いずれの場合もフルロードのシステムを使うことは攻撃対象領域を広げてしまう可能性があります。
仮想マシンやコンテナが持つ隔離性はベアメタルサーバのそれと同程度ではありません。Google提供のgVisorといった技術を使えば、セキュリティ層をさらに追加することが可能です。以上すべてから、セキュリティ戦略の策定は慎重に行う必要があることを示しています。
マシン間の全通信はトランスポート・レイヤー・セキュリティ(TLS)プロトコルをもって安全に行うことが推奨されます。通信をするにあたり、可能な限りプライベートIPを介して行われるべきです。保存データはAES-256を用いて暗号化し、適切なデータ管理対策を実施しましょう。これは組織のプライバシーポリシー遵守及び契約上の義務履行に大いに役立ちます。
マイクロサービス型のアプリケーション展開の台頭に伴い、APIキーはリスクの源となっています。これらAPIキーを安全ではない形で使用しているケースがしばしば見られます。一旦サービスが侵害されると、そのサービスが別サービスで使用するキーも攻撃者に盗まれ、五月雨式に侵害が発生する恐れがあります。APIキーを持つデプロイスクリプトがバージョン管理システム上で暴露される例は非常に頻繁に見られます。
自信をもってクラウドをご利用ください。当社の総合的なクラウドセキュリティサービスならお客様のすべての課題にお応えいたします。