この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、臼田です。
みなさん、AWSのセキュリティ対策してますか？(挨拶
今回は2021年5月11 - 12日で開催されているAWS Summit Online Japan 2021のセッションレポートです。
様々な利用部門でAWSが使われている会社さんが参考にできそうな事例でした！
セッション概要
セッション名: IT 子会社による AWS の社内プラットフォーム化と AWS ID ガバナンス (CUS-49)
スピーカー: パナソニック インフォメーションシステムズ株式会社 IDCサービス事業部 プラットフォームサービス部 クラウド・セキュリティチーム チームリーダー 小倉 達也 氏
概要: "コングロマリッド製造業におけるAWS アカウントの管理運営までの道のりと、セキュリティガバナンスについて、IT子会社が果たす役割を考える" 現在、AWSの活用方法などWeb上で容易に情報が得られるようになり、IT子会社を介さずともこれらの情報にアクセスすれば各組織である程度の活用ができる時代になりました。そんな中、IT子会社が果たすべき役割は何なのかを考え、何を実現したのかを紹介します。また、活用し易くなった反面、AWS環境が容易に作成できるため、セキュリティ上の脅威となり得ます。PanasonicのAWS IDのガバナンス活動についても合わせて紹介します。
レポート
- 大きく2つのテーマ
- 社内プラットフォーム化
- AWS ID管理
- パナソニックインフォメーションシステムズは2つの側面がある
- グループのIT戦略を担う中核会社
- 社外に向けて提案するSI事業
- 小倉氏はグループ内向けのしごとをしている
AWSの社内プラットフォーム化
- 背景
- 2012年ぐらいまでほぼすべてのシステムをデータセンターで利用していた
- ビジネス部門からAWSを使いたいという要望が出始めて利用を開始した
- 2016年頃からグループ内でAWSの利用が急加速してきた
- ビジネス部門もAWSに慣れてきて、Web上にもナレッジが充実してきて社内IT部門の価値とはなんだろうかと考えた
- Panasonicが扱う商品が幅広く、クラウドでいろんなサービスを検討したいというニーズがある
- どうすればもっとAWSを活用しやすくなるのかを検討することにした
- システム構築・運用する上で各システム担当が準備すること
- 全社のルールとプロセスに準拠する
- ルールの読み込みや準拠するための設計構築運用が必要
- 申請と審査も必要
- AWS運用体制
- メンテナンス通知の対処やAutoScaling、インスタンスタイプ変更
- バックアップ・リストア
- 障害対応
- などなど
- セキュリティ管理
- ログのチェック
- 設定不備確認
- 個別回線
- イントラネットと連携する場合に回線を準備
- AWSと言えどもネットワークの知識は必要
- これらはAWSを使うこと自体で楽になることもあるが、各システム担当部門が準備するのが大変
- 仕組みをパッケージにして提供することに
- iFlexという名前のパッケージにした
- 全社のルールとプロセスに準拠する
- やっていること
- コンセプトはAWSの社内プラットフォーム化で手続きはより簡単に、セキュリティはさらに強化
- 全社ルール・プロセス準拠
- 予めiFlexチームでルールの理解をして設計
- 所定の設計に乗っ取る構成は社内の申請が通った状態で利用可能
- 運用体制
- 24365のチームに落とし込み済み
- セキュリティ管理
- 問題がある設定をできないように制御
- Well-Architectedフレームワーク / ISO27017 / 社内ルールに準拠できるように監視
- 個別回線
- iFlexチームで十分な帯域を準備して論理分割して提供
- 順調にAWSのアカウントが増えて、活用が進んだ
- まだ個別管理のAWSアカウントが存在していた
- そのためID管理をしっかりしていくことにした
AWS IDガバナンス
- Panasonicではクラウドを活用するにあたり、クラウドの信頼性やネットワーク設計上の問題がないか確認するプロセスが整備されている
- 保存する情報に応じたセキュリティ
- 法務・セキュリティチェック・品質
- ネットワーク設計・設定のチェック
- これらを各部門でチェックすることに
- 理想としては統合・一元管理したほうがいい
- それぞれの組織で管理する場合には以下のようなリスクがある
- 全体管理されていないアカウントでインシデントが発生した場合、対応に時間がかかる場合がある
- 特に社外から連絡を受けた場合などにリスクが高い
- それぞれの組織で管理する場合には以下のようなリスクがある
- 実態をまず確認した
- iFlexを利用していないのは運用が不要であったり、小規模な環境などだった
- 原因
- コスト
- 運用や回線の付加価値をつけている分費用が発生する
- 管理外のものはコストが最重要
- iFlexの存在を知らない
- 担当者レベルまで隅々に情報を届ける必要があった
- コスト
- 各組織の課題感
- 本社
- 管理できていないAWSアカウントのリスクを排除したい
- iFlexチーム
- 小規模環境でもiFlexを使ってほしい
- 知名度を上げたい
- 各利用部門
- コストをなんとかしてほしい
- 本社
- サービス体系を見直した
- 支払い代行サービスを用意して、手数料を取らないプランを作成
- 支払い代行でもEnterprise Supportが利用できるように
- 専用契約条件も
- コストを抑えつつメリットを出せるようにして移行を促した
- アカウントの構成と運用の概要
- 利用部門はiFlexに申し込むとAWS Organizationsを利用してアカウントを作成
- 管理情報を取得できるので対応がスムーズになった
- 知名度アップの施策
- トップダウンとボトムアップ両方実施
- 全社員向けポータルやメルマガで発信したり
- グループ内のAWSイベントを開催したり
- AWS Summit登壇
- Panasonic社内でのAWSイベント開催
- 各部門を超えたネットワーキングの機会となるように実施
- 2020年は最大200名が参加して好評だった
- エンジニアとして新鮮な気持ちで参加できる
- 各組織の課題に対して解決できた
- 次の取り組み
- iFlexの支払い代行サービスでもセキュリティ管理のサービスを付けていきたい
- 費用をどうするかで悩んでいる
- 意図しない設定ミスでセキュリティリスクが生まれても自動検知できる
- 社内の審査プロセスを効率化できないか検討
- コンセプトにそって進めていく
- iFlexの支払い代行サービスでもセキュリティ管理のサービスを付けていきたい
- 目指す姿
- FANを拡大したりコミュニティ化をしたりとヨコのつながりを強化していくことなどがキー
まとめ
ただ単に全体管理を強制するわけではなく、利用部門のニーズも適切に把握して選択肢を提示する、仕組みを整えるというところを実践されていて素晴らしい事例だと思いました！
セキュリティ強化の具体的な仕組みのところもぜひ伺ってみたいですね！
12
