ビルダーのビルダーによるビルダーのためのセキュリティ

ビルダーの皆様、こんにちは。シニアセキュリティソリューションアーキテクトの桐山です。

皆様は、AWS 環境においてどのようにセキュリティを実現していますでしょうか ?

セキュリティ考える余裕が無い、セキュリティ実現したいけど方法が分からない、セキュリティやってみたけど運用が回らない、など多種多様なお悩みを私は今まで聞いたことがあります。

そのような皆様に向けて、今後数回にわたり、ビルダーとセキュリティを取り上げた連載をお届けしよう思います。

本記事は AWS Builders Online Series のセッション「ビルダーのビルダーによるビルダーのためのセキュリティ」の解説記事になります。セッション資料は以下をご参照ください。

セッション資料 »

X ポスト » | Facebook シェア » | はてブ »

builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。 

ここから皆さんの業務におけるセキュリティについて考えていきましょう。

どんな業界・規模の企業もセキュリティは意識しています。それに呼応するようにセキュリティ製品・サービスは巷に溢れています。それ自体は素晴らしいことです。一方で、セキュリティとはとかく状況に依存するものでもあります。皆さんが所属している会社毎に、業界が異なり、ビジネスモデルが異なり、事業の成長ステージが異なり、扱うアプリケーションやデータが異なるので、そのような状況に基づいたセキュリティ実装はその企業にしかできません。

• ビジネス要件に基づく IT 環境 (OS 、ミドルウェア、アプリケーションなど)
• ビジネスで扱う重要データの属性
• 企業内の他システムとの連携

状況の変化が激しい中、上記のような観点をセキュリティ実装に継続的に反映させるためには、皆さん自身がビルダーとなってセキュリティを作っていかなければなりません。

次に、プラットフォームに標準機能としてセキュリティが組み込まれることで、今まで以上にセキュリティ関連のログや検出事項が出てきます。今まで見えていなかったものが見えるようになったこと自体はとても良いことです。一方で、従来のやり方のままではセキュリティ監視・分析・監査などに必要な労力や時間が増えてしまうことになるので、自動化による効率化の余地が大きい領域でもあります。たとえば、 Amazon GuardDuty による脅威検知、 AWS Security Hub によるセキュリティリスク可視化、 AWS Audit Manager による自動証跡収集などは、セキュリティ関連業務効率化に寄与します。

そして、自動化は信頼性を向上させるという効果もあります。人間が手動で作業することで生まれやすい品質のバラつきは、ツールによる自動化で一定以上の品質が担保されます。また、AWS セキュリティの原理原則に “人をデータから切り離す (Keep the people away from the data)” というのがあります (参考 : AWS re:Invent 2017: AWS Security State of the Union)。重要データに人間がアクセスするのは事故の元という考え方です。重要データにアクセスするのはツールのみにし、ツールを開発・構成したり使用可能な状態にするのが人間の仕事であると言っています。

ここまでセキュリティを作る話をしてきましたが、それは何のためかというとビジネスの成功のためです。ビジネスの成功のために、主に事業部門 (Line of Business : LoB) にてサービス開発が行われますが、その開発に従事されている方ももちろんビルダーです。ここからはビルダーのためのセキュリティがどういうものか考えてみましょう。

従来、事業部門から見たセキュリティ部門は、“門番 (Gatekeeper)” のような存在だったかもしれません。サービス開始前のリリース判定会議でセキュリティレビューを実施、「項目 X 番のセキュリティルールに遵守していないので、やり直してください」などのやり取りが行われていると聞いたことがあります。実際、私がソフトウェア開発者だった時にこのようなことを体験しました。当時は、多くの工数を割いて対応していましたし、それが当たり前だとも思っていました。しかし、振り返ってみると、結果としてサービスリリースの時期が遅れ、ビジネスの機会損失につながるので、もっと良いやり方があったのかもしれません。

クラウドの特長として、 Infrastructure as Code という概念がよく使われます。サーバー、ネットワーク、ストレージなどのインフラをプログラムコードで記述し、ワンクリックでそのインフラが構築されるという特長です。プログラミングによるソフトウェア開発と同じようなやり方でインフラも作れてしまいます。

このような環境になったことで、セキュリティも規範的 (prescriptive) にコード記述できるようになりました。まだ存在していないシステムのセキュリティを先にコード記述しておけますし、ワンクリックでシステムが構築されると同時にセキュリティ実装もなされます。結果としてガードレールの敷設が、いつでもどこにでもコスト最適でできるようになったのです。

ガードレールの一例として、AWS Innovation Sandbox ソリューションというものをご紹介します。 まさに、イノベーションを起こしたいビルダーが実験的な場として利用できるサンドボックス環境です。安心・安全な実験場を作る上で、AWS Organizations による AWS アカウント管理、AWS CloudTrail による監査用操作ログ取得、データ漏えいを防ぐため Amazon AppStream 2.0 によるブラウザベースアクセスなどが含まれています。AWS 環境において、開発しているアプリケーションの実証実験 (Proof of Concept: PoC) をしてみたい方は是非ご参照ください。

以上、ビルダーとセキュリティの話をしてきました。クラウド技術を使うことで、ビジネスを成功に導くセキュリティが実現しやすくなったと言えます。皆さんの会社でも実現できそうでしょうか ?

「そんな簡単にはいかないのよ」という声が聞こえてきそうです。この記事ではまだ、前述の DevOps 要素である手法 (Practices) とツール (Tools) の例を述べただけで、組織文化 (Culture) に触れていないからかもしれません。

セキュリティはセキュリティ専門チームだけのものではありません。企業に属する全員がセキュリティ意識を持った文化を維持する必要があります。組織文化は企業毎に異なるので一般化はできないため、ここでは AWS ではどのようにやっているかを紹介しようと思います。

一度決めたとしても、それがまるで形骸化したルールのように組織や人を縛り付けるものになってはいけません。AWS では、何かを決める時、これを魔法の言葉のように付け加えて、常により良いものを探し続けるということを心掛けています。仮に失敗したとしても早く前向きに失敗して、次のより良いものを求める、これもビルダーのビルダーによるビルダーのためのセキュリティ文化の一端と言えるのかもしれません。

次回からは、ビルダーに向けたセキュリティ実装方法やワークショップのご紹介などをしていく予定です。ビルダー向けの AWS セキュリティサービスや新しい機能にも触れていくので、連載をお楽しみにしてください !