【TECH連載】AWSのFTRレビュー通過までの取り組みについて
【TECH連載】では当社エンジニアによるテック関連のニュースを中心に記事をお届けします！
こんにちは、AICROSS開発チームの樋口です。
弊社AICROSS株式会社はこのたび「絶対リーチ！SMS」と「セキュアSMS認証」AWSのFTRレビュー(ファンデーショナルテクニカルレビュー)を通過し、AWSによりソリューションのセキュリティ、信頼性、運用上の優秀性において一定の基準を満たしている事が第三者の観点から認められました。
弊社の開発チームはこれまでに1年をかけてAWSが推奨するベストプラクティスAWS Well-Architectedに基づいて各種サービスの設計と運用を見直していく全体の開発標準の取り組みを行ってきました。
今回、FTRレビューの準備からFTR通過までは2か月の期間でしたが、この事前の開発標準の取り組みがなければFTR通過は難しかったと感じています。
今回は、弊社の開発チームが行ってきた開発標準の取り組みの一部を紹介したいと思います。
事前の取り組み１ - インフラ設計の標準化と各種サービスへの適用
✅ インフラ共通設計と各種サービスの適用
開発標準の取り組みの１つはインフラ設計の標準化です。
インフラの標準化では全サービス共通となるインフラの基準の策定をしていき、基準を満たしていないインフラリソースへ適宜適用していく取り組みを行ってきました。
策定したインフラの基準としては以下のようなものです。
・各種リソースは必ず暗号化をおこなうこと
・セキュリティグループの範囲を最小にする。
（ここは設計書＋Trusted Advisorなども活用して設定の緩いセキュリティグループを洗い出していく）
・ロール／ポリシーの最小
・シークレット情報の管理はシステムズマネージャーのパラメータストアのシークレット属性などに設定
・各種リソースの命名規約の統一
・Public IPを持つサーバ(EC2)の排除（業務上必要な場合はIP制限などを実施)
等
上記はAWSの開発者にとってはわざわざ書かなくても理解しておくべき「当たり前」の事ですが、各個人が知っている100個の「当たり前」を技術者全員が必ずしも100個すべてを共有できているとは限りません。
個人が持つナレッジを集約して組織のナレッジとして共有していくのが共通設計となります。
技術者個人が全員100点満点のナレッジを持っていなくても、組織で100点満点のナレッジがあれば良い、という考え方のもとに、技術者間で共通設計を通じて情報共有と見直しをおこない、この共通設計を継続的に育む活動を続けています。
✅ Cloudformationのテンプレートの整備
弊社ではインフラリソースはCloudfromationを中心に構築しています。
共通設計の整備とあわせてテンプレートとなるCloudfromationの整備も行っていきました。
これは、新規サービスの構築に流用していくことによりインフラ構築の生産性向上やセキュリティ対策の漏れの防止を目的としています。
✅ 設計書の記載内容、記載粒度の標準化
また、各サービスの設計書（wiki）の章立てや記載粒度などは参考ルールとしての基準を用意しています。
これはインフラ設計以外にもアプリケーション設計も対象にしています。
開発チーム全体の方針としては、設計書の記載内容や記載粒度は各サービスごとに任せる、を原則としています。
これは様々な開発手法や採用する技術要素に対応するため、また各チームの自由度や自律性を阻害しないための原則としています。
一方で「継続的に」「正しい情報を」ドキュメントに残していく文化も育成していく必要があったため、書きすぎでメンテナンスされない設計書を抑制することを目的として
・wikiに記載する設計書はメンテナンスできる最低限の量に留める
・細かい設計は開発者が書きやすいread.meやソースのコメントに残す
を参考ルールとしています。
事前の取り組み２ - 運用設計の標準化と各種サービスへの適用
インフラの共通設計と並行して、各サービスでばらばらだった運用の共通化を行っていきました。
例として、AWSアカウント管理など共通化可能な運用は、共通的な管理台帳や承認フロー、棚卸ルールを整備して、全チームの運用を一元的に管理するように見直しています。
またセキュリティの観点としてCloudTrailの監視ルールを統一して、不正もしくは不正が疑われる操作の監視を行い、可視化できるように運用を整備していきます。
弊社ではITILv3をベースに運用の項目を整備して、「共通化できる運用」「個別のサービスで設計する運用」に分けて、共通化できる運用については、運用の共通設計として策定して、サービス単位で準拠していない共通運用については、順次見直しをおこなっていきました。
事前の取り組み３ - AWSコスト最適化
インフラ整備と運用整備を行った上で、開発メンバー全員にAWSのコストを意識する文化を育成するためにコスト最適化の取り組みを行っていきます。
こちらは前回のNoteで紹介していますので参考にしてください。
FTRレビューの実施
これまでの開発標準の取り組みを行ってきた上で、AWSのFTRレビューに挑んでいます。
弊社としては開発標準の取り組みの中で十分な対策を実施してきたつもりでしたが、外部の第三者からの視点での気づきを頂けたのはありがたいことでした。
FTRレビューで主に指摘された内容としては次の通りです。
✅ 指摘１：運用の自動化
セキュリティ関連のチェックなどは弊社は構成管理者による定期的な棚卸による目視チェックの運用が多く残っていましたが、監視アラート化により即時で検知する仕組みがあれば改善したほうが良いなど、運用の改善を何点か指摘を頂いています。
✅ 指摘２：システム設計および運用設計の明文化
システムを運用していく上での「当たり前の事」は多くありますが、それが設計書もしくは運用設計として明文化されているか？は改めてチェックすると漏れている事がいくつかあり、今回のFTRレビューではその部分の気づきが多くありました。
✅ 指摘３：曖昧な運用ルールの排除
運用ルールとしては決まっているが曖昧なものがないか？は今回のFTRレビューでは指摘されています。
例えば、アカウント台帳の棚卸日も「具体的に」何月の何日に実施するのか、それがルールとして運用手順に記載されまたカレンダーとしても共有されているか、などは指摘されています。
最後に
弊社開発チームでは全サービスのFTRレビューの通過を目指しています。
また、FTRレビュー通過済のサービスにおいてもAWSの進化に伴い、開発標準の見直しや、さらなる運用の効率化を行っていく必要があることから、今後もAWSのFTRレビューを通してAWS Well-Architectedに基づいた更なるサービスの改善を目指していきたいと考えております。
この記事が気に入ったらサポートをしてみませんか？