はじめに

本記事はアイレット株式会社新卒 Advent Calendar 2023 の12日目の記事です！

今年新卒で入社した私がAWSの運用について興味のある分野を調べてみました。
記事の内容に自信はありませんが、将来の自分のためにもアウトプットを行ってみました！

この記事を読むと以下のことを理解できます。

運用とはなにか
アカウント運用とセキュリティ統制方法

システムの運用とは？

システム運用とは、システムがリリースされてからサービス提供が終了するまでの間、安定的にシステムを稼働させ続けるためにシステムを維持・管理することをいいます。例えば自社でB to Bシステムを提供しており、顧客のシステム運用を怠ってしまうと、システムが停止してしまう可能性があります。これは顧客の業務に影響を与え、顧客ビジネスの利益に影響します。顧客にとって「維持管理を任せているのにシステムが停止し、利益も損なってしまった」となるとサービス利用の解約に繋がります。運用をするということは顧客のシステムを安定して稼働させる、自社で提供するサービスをの利益を守るということです。

基盤運用

システムを安定稼働させるための運用を基盤運用といいます。AWSの基盤運用の中でも今回は

アカウント運用
セキュリティ統制

に触れていきます。

アカウント運用

複数アカウントの所持

複数アカウントの所有は以下のメリットがあります。

アカウントごとの料金管理
アカウントごとに利用者のアクセス管理
アカウントごとのアクセス管理でユーザーの誤操作を防ぐことが出来る

アカウントを複数持つと、各アカウントへのアクセス管理が複雑になるのでは？となります。これはアカウントを3つ作成し、各アカウントにIAMユーザを適宜作成するなどが例です。複数アカウントを所持する場合は「ロールの切り替え」を利用して管理を実現します。

ロールを利用したアクセス管理

切り替え元となるアカウントを1つ用意します。これを「踏み台アカウント」と呼びます。
以下のように踏み台アカウントとその中にIAMユーザを2つ用意します。

踏み台アカウントのIAMユーザでログインし、他のアカウントへ権限をロール切り替えしログインします。ログイン先のアカウントではロールに付与された権限でのみ操作を行えます。

踏み台アカウントと切り替え先アカウントでの作業内容

踏み台アカウント
踏み台アカウントのIAMユーザポリシーに追加する内容として、切り替え先のロールをsts:AssumeRoleする必要があります。これは一時的なセキュリティ認証情報の作成許可を与えるという意味です。この操作により踏台アカウントのIAMユーザは一時的な認証情報を用いて切り替え先アカウントのロールの権限をassume(引受)し、ロール内の権限を利用できる仕組になっています。逆に追記してあげないと切り替え先ロール内の権限を使用できません。

policy

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "<ログイン先のAWSアカウントのIAMロールのARNを追加>"
  }]
}

デフォルトで、IAM ユーザーには、フェデレーティッドユーザーおよびロールの一時的なセキュリティ認証情報を作成するアクセス許可がありません。ユーザーに上記の権限を提供するポリシーを使用する必要があります。

切り替え先アカウント
踏み台アカウントのIAMユーザに対し切り替え先アカウント内のロールから信頼ポリシーのPrincipalで権限を委任する設定をおこないます。Principalはだれがこのロールを引き受けることができるかを指定できる要素になります。同時にsts:AssumeRoleも含ませます。

policy

{
  "Version": "2012-10-17",
  "Statement": [
      {
        "Effect": "Allow",
        "Principal": { 
            "AWS": "arn:aws:iam::<踏台アカウントのID>:root" 
        },
        "Action": "sts:AssumeRole"    }
  ]
}

IAMグループで各ロールへのアクセス制御

踏台アカウント内でIAMグループを作成し、グループへユーザを追加することで各アカウントへのアクセスを制御します。切り替え先アカウント内が1つで、中に読み取り用と操作用の2つのロールを用意する場合、グループのポリシーにsts:AssumeRoleと切り替え先アカウントのIAMロールARNを含ませます。グループごとにロールへのアクセスを制御することで開発グループにはアカウント内の操作権限を、問い合わせ担当には読み取りのみの権限を分けることが出来ます。

セキュリティ統制

AWS認定資格CLFを学習された方なら効き馴染みのあるセキュリティの3要素「機密性・完全性・可用性」の要素ですが、これら全ての脅威に対応するのは現実的でないと言えます。これらの理由をお伝えします。

コストの問題
セキュリティ対策をサービスに施すほどコストがかかるからです。セキュリティ対策を実施すればするほど、より強固になりますが反面、セキュリティ対策にかかる費用がかさみます。対策の費用というのはAWSのセキュリティサービスのランニングコストのことです。そしてセキュリティ対策を維持するのに人員配置や人材教育などの費用もかかるため、持続的な維持には予算を費やせ得るだけの資本的な体力が必要になります。
周囲の理解が必要
セキュリティ対策によって得られている効果が目に見えにくいからです。セキュリティ対策は脅威から企業を守ることは出来ても直接的に企業の利益になることはありません。セキュリティ対策ソフトなどで企業は攻撃から情報を守りますが、守られている状態が続くことで業務が停止してしまうようなインシデントに繋がらないため、実際の利益への効果が実感しにくいからです。ですが実感しにくいだけで導入した企業は完全性の恩恵を確実にうけています。
ここでもBtoBでサービスを提供している側の企業に立って説明すると、その企業で完全性が保たれていない状態は信用問題につながります。なぜならデータを盗まれたり改ざんの被害を受けることが考えられるからです。これは「その企業が持つ情報を信用できない状態」ということになります。ですが完全性を維持するためにサーバーにウイルス対策ソフトを数百万のコストをかけて導入した結果、企業内の重要な情報の正確性が保たれ「企業が持つ情報を信用できる状態」となり、顧客にも安心してサービスを利用してもらえるので、直接的な利益とはなりませんが「利益を生むための前提条件が確保されている」ということになります。
ウイルスなどの攻撃手法の進化
ウイルスなどは日々進化し続けそれらがいつ現れるかなどの予想がつかないため、多額の資金を投じてセキュリティ対策を実施しても、新しい脅威によって破られる可能性を否定できないためです。

どのように対策すべきか？

対策は主に「セキュリティ標準」「予防的統制」「発見的統制」の3つから対策します。

セキュリティ標準から検討する
紹介した3つの理由からセキュリティを全て検討するのは現実的ではありません。どの程度まで検討・実施すればよいかは考え方・方針が「セキュリティ標準」にあります。セキュリティ標準にはセキュリティに対する具体的かつ網羅的な文章が掲載されているのでセキュリティ標準を指標として検討・実施ができます。
予防的統制とは？？
↪「リスクや脅威が顕在化することを未然に防ぐ」という観点であり、権限のないユーザーによる意図しない書き込みアクションを阻止する、ロールやポリシーが該当します。
発見的統制
発見的統制とは??
↪「早期発見および迅速な対処を実現」という観点であり、自動化されたアラート通知や、AWS Config は設定履歴の確認とSecurity Hubで検知。Amazon GuardDutyで、悪意ある動作や不正な挙動を継続的に監視するなどがAWSでは該当します。

Roleやセキュリティグループで予防的統制のみ行うというのが基本ですと先輩教わりました。発見的統制は各サービスの利用料が高く、絶対にセキュリティインシデントを起こすことのできないサービスなどでは導入されているそうです。

まとめ

今回は「AWS運用入門」という技術書のアウトプットを行いました。今回のアウトプットを通して、点だった知識が線になった感覚を実感し、とても楽しかったです！アドカレはまだまだ続きますので、今後もよろしくお願いします！

運用 is Nani