ITとかCockatielとか

技術のこととか。飼鳥(オカメインコ)のこととか。気になったこととか。基本的には備忘録。

AWSクラウドのセキュリティ メリット・責任範囲

AWSクラウドのセキュリティ メリット・責任範囲

AWSセキュリティのメリット

  1. データの保護
    データ保護のための安全対策が用意されている。
  2. コンプライアンスの要件に準拠
    コンプライアンスプログラムを管理でき、コンプライアンスの一部は最初から達成されている。
  3. コスト削減
    AWSデータセンターの利用により、セキュリティにかかるコストを削減できる。
  4. 迅速なスケーリング
    ビジネス規模に関わらず、セキュリティをスケーリングできる。

責任範囲

物理

AWSのデータセンターのセキュリティはAWSの担当。

  1. 環境レイヤー
    • 自然災害などの環境リスクを軽減するため、設置場所は慎重に選択されている。
    • 各リージョンのデータセンター群は互いに独立・隔離されている。
  2. 物理的な境界防御レイヤー
    • データセンターは物理的に防御されている。
    • その境界には保安要員、防御壁、侵入検知などがある。
  3. インフラストラクチャレイヤー
    • インフラとして建物や各種機器、それらの運用に関わるシステムなどがある。
    • 発電設備や消火設備などが、ユーザーのデータ保護に役立っている。
  4. データレイヤー
    • ユーザーデータのため最もクリティカルなポイント。
    • アクセス制限や特権の分離を行う。

ハイパーバイザ

  • ハイパーバイザのセキュリティはAWSの担当。

管理プレーン

  • 管理プレーンの保護はユーザーの担当。

※管理プレーンとは、クラウドを管理する面(プレーン)、つまり管理コンソールなどの総称として捉えておくと良さそうだ。

  1. ID、パスワード
  2. ルートアカウント
    • すべての操作が可能な、最も強い権限のアカウント。
    • 日常作業は別アカウントに適切な権限を割り当てて利用する。
  3. キーペア
  4. APIキー
    • Webブラウザではユーザー名/パスワード を利用するが、コマンド・プログラムではAPIキー(アクセスキー/シークレットアクセスキー) を利用する。
    • APIキーはユーザー単位で発行可能。
    • ルートアカウントへの発行はリスクが高いため推奨しない。
    • ソースコードへのAPIキー埋め込みは推奨しない。環境変数や認証ファイルでの設定が適切。
    • 現在はAPIキーの利用そのものが推奨されていないIAMの利用が推奨される。

マネージドでないサービス

  • マネージドでないサービスのセキュリティ責任はユーザーにある。
  • IaaSサービスはユーザーがroot、Administrator権限を持つため、セキュリティ設定はユーザーが行う必要がある。(オンプレと同等)

マネージドサービス

  • マネージドサービスでは、リソースへのアクセスコントロールと、アカウント認証情報の保護のみがユーザー責任。
  • 但し、一部のサービスではさらなる追加作業が必要。
  • プラットフォームはAWSの責任、データなどはユーザー責任。