Security-JAWS【第27回】で登壇した内容です。 s-jaws.doorkeeper.jp
こんにちは、クラウドセキュリティアーキテクトの大島悠司です。
スピード重視の開発を行ってきたスタートアップ企業にとって、現在のセキュリティ対策に不安を感じる方も多いと思います。
今回は、弊社で実践してきたAWSセキュリティ対策を、特に内部統制に軸を置きながら、その観点や実装方法をご紹介します。
内部統制の重要性
内部統制とは、組織の業務の適正を確保するための体制を構築していくシステムです。
簡単に言うと、企業が事業を効率的かつ健全に運営するための仕組みのことです。
内部統制には4つの目的があります。
- 業務の有効性・効率性
ヒト・モノ・カネ・情報といった経営資源が無駄なく活用されていること。 - 財務報告の信頼性
財務報告の内容に誤りがないか、チェックする体制があり信頼性が確保できていること。 - 法令順守
企業倫理や法令順守が徹底されていること。 - 資産の保全
会社の資産が適切に管理・活用されていること。
そして、内部統制には6つの基本的要素があります。
- 統制環境
組織風土や、従業員の統制に対する意識に影響を与える基盤 - リスクの評価と対応
リスクを識別し、分析・評価を行ったうえで適切な対応をする一連のプロセス - 統制活動
経営者の命令や指示が適切に実行されるように定められた手続き - 情報と伝達
必要な情報が適切に識別・把握・処理され、組織内外および関係者相互に正しく伝達される一連のプロセス - モニタリング
内部統制が有効に機能しているかを継続的に監視し、評価・改善を行うプロセス - ITへの対応
事業に必要なIT技術を、あらかじめ定めた適切な方針や手続きのもとで利用すること
特に6つ目のITにおける内部統制において、IT技術の高度化・複雑化とともに、その重要性は日々増しています。
サイバー攻撃が巧妙化する一方で、内部不正やリスクコントロールの不備による情報漏洩も後を絶ちません。
クラウド化が加速する現在、不特定多数のアクセスにさらされるクラウド利用における統制はさらに重要になり、健全なシステム運用、アクセス統制や権限管理が必要不可欠になっています。
スタートアップこそ内部統制に気を使うべき理由
スタートアップの爆発的な速さ
スタートアップという組織は、とにかくリリース頻度が速く、セキュリティ対策が二の次になりがちです。
ルールがない中でどんどんプロダクトが増加したり、プロダクトの追加や検証で急にアカウント追加が必要になることは日常茶飯事です。
急に求められるセキュリティの水準向上
セキュリティ監査や認証取得、ステークホルダーからの要求に応えるために急遽セキュリティ水準を高めなければならない時が来ます。
スタートアップといえど、将来的には事業が拡大していきます。
そのため、遅かれ早かれ内部統制の対策に時間をかける必要性が出てくるので、初期段階でしっかりセキュリティ対策をし、統制の取れた運用を根付かせることが大切です。
アカウント分離とIAM設計
スタートアップは短いスパンでリリースが行われ、ワークロードが日に日に増えていくので、アカウントの構成は初期段階でしっかりと設計するべきです。
シングルアカウントだとすぐに運用が滞ってしまうので、最初からマルチアカウント構成で組んでおきましょう。
同時に、IAMの設計もよく考えておきましょう。
アカウント設計とIAM設計のポイントは、以下のブログをご覧ください。
何のログをどのアカウントに集約し、どのアカウントで横断調査できるようにするかなども考慮しながら検討するとよいでしょう。
以下にマルチアカウントの構成例を示します。
AWSには、マルチアカウント構成を手軽に実現するサービスが用意されていますので、必要に応じて活用しましょう。
AWS Organizations
- 複数アカウントの一元管理
- アカウント管理の自動化
- 一括請求
AWS Control Tower
以下を含めたセキュリティサービスの一括設定
- AWS Organizations
- AWS Single Sign-On
- AWS Service Catalog
- AWS Config
- AWS CloudTrail
Change Managerによる本番アクセス統制
本番環境へのアクセス統制はしっかりと対策しておきましょう。
スピードを優先しすぎるあまり、開発メンバーが誰の許可も得ず本番環境の変更をしてしまうことは避けておきたいです。
Change Managerによる本番アクセス統制の実装方法は、以下のブログをご覧ください。
統制上考慮すべき権限
権限設定例
請求情報の閲覧禁止
プロジェクトには社外のメンバーが入ることもあります。
必要以上に金銭情報を把握されないために、明示的に拒否すると良いでしょう。
IAMユーザはデフォルトで請求情報にアクセス不可で、アクセスのアクティブ化とBilling閲覧権限が必要になります。
ただし、Organizationを組んでいる場合、Organizationから作成されたメンバーアカウントは本設定がデフォルトでONになっているので注意する必要があります。
IAMユーザが所属しているグループと、スイッチ先のロールにaws-portalを拒否するポリシーを付与すると良いでしょう。
aws-portalを明示的に拒否する例
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "aws-portal:*", "Resource": "*" } ] }
S3オブジェクトのダウンロード禁止
本番ワークロードでは、S3に個人情報などの機微な情報を扱うことも多いです。
注意しなければならないのは、閲覧権限だけ与えればよいと安易に「ReadOnlyAccess」を設定しただけでは、オブジェクトダウンロードができてしまうため、明示的に拒否しましょう。
S3:Getを明示的に拒否する例
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "s3:GetObject", "Resource": "*" } ] }
明示的な拒否ポリシーが付与されている状態でオブジェクトダウンロードしようとすると失敗する例
S3オブジェクトの削除禁止
サービスに必要なデータやTrail/Configログといったデータを削除させないようにしましょう。
明示的に拒否するほか、オブジェクトロック機能を利用することも検討するとよいでしょう。
S3:Deleteを明示的に拒否する例
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "s3:Delete*", "Resource": "*" } ] }
ネットワークの作成禁止
不要なネットワークを作成させないようにしましょう。
特にスタートアップのように開発スピードが速い現場だと各々がネットワークを作り、管理者の気づかぬうちに出口経路が増えているケースがあります。
管理されていない出口経路は情報流出の元なので、作成権限を与えないようにするとよいでしょう。
VPC/IGW/NATGWの作成を明示的に拒否する例
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "ec2:CreateVpc*", "ec2:ModifyVpc*", "ec2:AttachInternetGateway", "ec2:CreateInternetGateway", "ec2:CreateNatGateway" ], "Resource": "*", "Effect": "Deny" } ] }
IAM操作の禁止
必要以上に高権限のポリシー作成や既存ポリシーの削除をさせないようにしましょう。
IAM操作を許可しない「PowerUserAccess」を開発者に与えるのもよいですが、以下のIAM権限を追加で与えておかないと、サービスが利用できないことがあるので注意です。
特定のIAM権限を明示的に許可する例
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "iam:Get*", "iam:List*", "iam:PassRole" ], "Resource": "*", "Effect": "Allow" } ] }
とは言え、サービス開発においてはロールの作成も必要になってきます。
そこで、IAM操作をCloudFormation経由で実施する運用にするといった方法を検討するとよいでしょう。
具体的には、IAMの作成権限を与えたCloudFormation用のロールを用意し、CloudFormation実行時にこのロールを指定させるという方法です。
手作業でIAM操作を実施されるよりも、証跡として分かりやすいですし、運用に不都合が出ればStackを削除するだけなので管理しやすくなります。
アカウント毎のIAM操作禁止権限と運用例
スタートアップにおいてはスピードが求められるため、開発を阻害しすぎないことも重要です。
例えば、以下のような運用は一例になります。
開発環境の権限を緩めておき、手作業のIAM操作を許容する。
開発者はここでCloudFormationテンプレートを作成し、ステージング環境や本番環境に展開します。
開発環境で過剰な権限作成がされるとアラートが飛ぶ仕組みを実装しておくと安心です。
まとめ
スタートアップこそ、早期に内部統制の視点でセキュリティ対策をする必要性があります。
マルチアカウント設計やIAM設計、本番環境アクセスの統制、各ユーザが与えられる権限が過剰でないかをよく吟味しましょう。
ただし、開発効率を落とさないために、使いやすさとセキュリティのバランスを考えて設計することが重要です。
