Workshop”に参加してきました。Securityの開発拠点であるオタワに集められ、以下のスケジュールでディスカッションやハンズオン等を行いました。それぞれをかいつまんでご紹介すると以下の様な内容でした。普段私たちがお会いするのは「情報システム(以下情シス)部門」の方々なのですが、クラウドサービスを活用し、サーバを多く所持するのは「事業部門」になってきています。セキュリティを気にする情シス部門と売上を気にする事業部門は視点が異なるため少なからず衝突があります。そこで、事業部門は情シス部門に相談することなく直接経営層に働きかけ予算を獲得するため、セキュリティ対策をあまり考えずにサービスを展開していきます。売上という経営層にも理解し易い指標で話すため情シスよりも大きな予算を獲得し易くなっています。この事実を受け入れ、事業部門がどの様なことを考え、どの様な動きがあるのかに着目し、顧客のクラウドシフトが安全に進むように支援していこうというマインドチェンジを促す内容でした。Securityにどう取り入れられているかの紹介でした。開発手法として一昔前に主流だったウォーターフォール型では刻一刻と変化する世の中のニーズに対応するのが難しくなってきました。そこで現在はDevOpsという考え方を取り入れ、世の中の変化に迅速かつセキュアに対応する開発手法が好まれています。開発者がコードの変更をかけると自動的にビルド、テストそしてリリース準備が実行されるといったパイプライン(流れ)になります。この一連の流れの中に従来のオンプレを意識したセキュリティ対策を入れてしまうと、自動化されたパイプラインの中で手動のオペレーションが必要になり、そもそもこのパイプラインがPaaSやSaaS、もしくはContainerで実現されている場合、従来型のセキュリティ対策の入る余地が無いかもしれません。Securityは従来のオンプレ環境だけでなく、各種サービス上で実行できたり機能だけを提供したりとパイプラインの阻害要因とならない工夫が取り入れられています。Checkを用いてContainerの脆弱性をスキャンするといったことも実現できるようになります。今後もそういった世の中の変化にいち早く対応できる提供形態を模索していくという内容でした。「Microservices」こちらも最近よく見かける単語ですね。従来のMonolithic(1つの塊)なアーキテクチャではなく、個別に開発された小さなサービスを組み合わせて1つのサービスを提供することで変化に対して素早く柔軟に対処できるというメリットがあります。Securityそのものをインストールできない環境(小さなサービス群)においても必要なタイミングで必要な機能のみを提供できるようAPIの公開に力を入れており、このAPIをSOAPからRESTに移行し、公式に提供していく予定です。Securityをより身近に感じていただけるような仕組みを考えているという内容でした。Cloud」この言葉自体はよく耳にするどころか、既に皆様の環境もこの様に構成されているかもしれませんね。社内のサーバをクラウドへ移行しようとしても一部オンプレにサーバが残ってしまうケースや、あえて一部を残すケースがあると思います。Securityでしたら1つの管理サーバで両環境のセキュリティ対策が可能です。これによりオンプレとクラウドでセキュリティレベルを統一させることができます。Securityで統一させるということが可能です。Securityはお客さまの環境に柔軟に対応できるという内容でした。Securityの今後の機能拡張については、予告なしに変更や見直しが入る可能性があります。Checkは現地時間6月に北米でリリースされましたが、日本での発売時期は未定です。reserved.sXpIBdPeKzI9PC2p0SWMpUSM2NSxWzPyXTMLlbXmYa0R20xk。