「ニッポン」電気の金融コンサル
釜山公徳氏（以下、釜山）：みなさんお待たせいたしました。釜山がお送りするのは「セキュア・アーキテクティング入門」です。よろしくお願いします。
（一同拍手）
まずは自己紹介します。私の所属は、みなさんご存知ですかね。日本電気株式会社というところです。これ「ニホン」電気じゃないですからね、「ニッポン」電気なので……。私、エバンジェリストをやりながら、コンサルタントをやったりアドバイザーとしていろんなプロジェクトに参画しています。メインは金融です。これでも一応金融のコンサルなんですよ。イエイ！ ……反応がない。
河野真一郎氏：イエイ！
釜山：はい。CompTIAであったりFin-JAWSとか、いろんな外部団体あるいはコミュニティに参画して活動しています。資格も多少持っていまして、クラウドに関係するやつを一通り貼ったような気がします。忘れてください。コラムとかも書いています。いろいろですね。
というところでこれぐらいにして、本日お伝えしたいこと！ 私はコンサルタントという立場でもあるので、コンサルタント視点でのセキュア・アーキテクティングのお話をします。技術要素として、ちょっと薄いかもしれません。入門という位置付けですので、私の話は流す程度でOKです。セキュリティマインドであったり、検討にあたって必要な概念、あとはセキュリティ技術カテゴリーについて簡単に紹介します。
今日お伝えしたいことは以上です。流しながら喋ります。ちなみにこのパワポのテーマなんですけど、釜山が急遽作りました。一応これ『逆襲のシャア』。ガンダムですね。νガンダムをイメージして作りました。はい、どうでもいいんだよね。
セキュリティは投資である
セキュリティマインドの話です。セキュリティは、コストは掛け捨てなのか？ よく言うんですよね。いや、もう黙ってくださいと。セキュリティは投資であると。これ私はもう5年、6年もっと前ぐらいからずっと言い続けていることなんです。「セキュリティは掛け捨てなのであまりやりたくないですね」と、よく言うんですね。トレードオフです。違うんですよ。
中途半端ないい加減なセキュリティを実装されても、利用者からするとそれって価値ないですよね。逆説で言うと、適切なセキュリティを投資・実装することによって、この環境あるいはプロダクトは価値が出てくるんです。つまりセキュリティは効果がないものではなく、費用も適切に掛ければ投資対効果が出てくるものだということを抑えてもらいたいなと思っています。
それに関する私の思いをNISCのコラムで書いています。セキュリティは投資です。URLを貼っています。この資料自体、後ほどSlideShareで公開します。
ということで、今日の私の言いたいことはこれで8割終わりましたね。
守りたいものを定義する
マインドのところをもう少しお話しします。守りたいモノをまず定義しましょう。よくあるんですね。とくにエンジニア方。「こういうIDS/IPS、いいのがありますね」と。「じゃあこれを実装しましょう」。あるいは「最近アンチマルウェアは機械学習を実装していますが、これいいんじゃないですか？」。違うんですよ。まずやるべきことは、製品の話であったりセキュリティのカテゴリーの話、そんなものではないんです。
守りたいモノをまず定義しましょう。データがどういうものであるか。例えば対象のデータに個人情報が含まれています。じゃあ個人情報が特定個人情報なのか否か。特定個人情報というのはマイナンバーですね。マイナンバーが含まれているものに関しては、法律がこれまでの通常の個人情報とは異なります。違反すると民事法ではなく刑事法のカテゴリーになるので刑罰の対象になりますとかですね。
ですのでそういった違反行為、違法行為を行った場合にどういうインパクトがあるか。これが2つ目のリスクベースアプローチです。守りたいモノが漏えいしました。その場合にどういったビジネスインパクトがあるのかというところ。ビジネスインパクトだけでなく組織内での過剰なリソースを取られて機能が回らなくなる。あるビジネス、プロジェクトが回らなくなる。そういったところを抑える必要がある。これがリスクベースアプローチ。
Biz＋DevSecOps
そしてDevSecOps、最近はよく聞きますよね。これにBizを足しましょうと。Biz＋DevSecOpsにすることによってどういうメリットがあるのか。この詳細については今日は省きますが、簡単にポイントだけ。
ビジネス影響を考える、サイクリックな開発、セキュリティオペレーションを設計、DevとOpsのシームレスな連携が必要であると。これ、当たり前のように思われる方がいらっしゃるかもしれないですけど、実際はどうでしょうか。振り返ってもらいたいですね。これらを実装することによって、どういうメリットが生まれるのか。ビジネスアジリティの向上、コスト最適化、時間対効果、情報漏えいリスク回避等々を実現することができます。
Bizをあえて入れてるのは、ビジネスの視点というのを入れないと、実装したものがけっこう空回りになるんです。昔からよくある話ですと、プロジェクトが1つありました。その要件をお客さんからいろいろ聞きました。できあがったものが全然違います。よくある話ですよね。
それはなぜか。いろんな要素があります。原因があります。ビジネスのことを考えていなかった。ビジネスサイドのCXOが丸投げしてきた。ですので、できあがったものがビジネスに直結しませんでした。まぁそんな話ですね。ですので、ここを抑えるべきである。
アカウントハイジャックの例
DevSecOpsの話をしたので、ここに例としてあるのがアカウントハイジャックという脅威です。これをどうやって具体的にDevSecOpsのサイクルに落とし込むか。まず、こういったアカウントセキュリティを、セキュリティの基本的な考え方を基に正しく設計しましょう。トレーサブルな設計であったりとかですね。こういった運用を考えた上での設計をまずすべきであるというところが、こちらからお伝えしたいポイントです。
3つのセキュリティ領域
そしてセキュリティの概念。3つのセキュリティ領域。Security X Cloudと私はよく呼んでいます。IN、BY、OFの3つの視点です。INは利用者側で講じる領域、BYはクラウドベンダーやセキュリティベンダー……セキュリティベンダー？ なんか聞いたことあるなぁ、エフセキュア……あぁ。みたいな、そういったところが提供するサービスで、Security as a Serviceと呼ばれることもあります。
Security OF Cloudは、クラウドベンダー側の責任範囲の話です。これを河野さんからも少しお話がありましたが、これを落とし込んでいるのがこのスライドです。カスタマー側の責任範囲について、IN、BYですね。INに関しましては従来の考え方＋αで、管理プレーン、あるいは管理コンソールと呼ばれる部分に対するセキュリティ施策が必要であるというところを抑えてただきたいです。
BYに関しましては、クラウドプラットフォーマーとしてAWSであったりMicrosoft、Google、Oracle、いろんなところがありますけれど、そういったところが提供するセキュリティ。例えば仮想ファイアウォール、AWSでいうとSGであったりNACL、セキュリティグループ、ネットワークアクセスコントロールリストですね。Azureでいうとネットワークセキュリティグループだったりアプリケーションセキュリティグループがあります。
それ以外に、AWSでいうところのInspectorという、脆弱性診断をするようなサービスもあります。クラウドベンダー側でさまざまなセキュリティサービスを提供しています。それを適切に利用しましょうというのがこのSecurity BY Cloudのところです。
そして最後にOF。こちらは本日細かいところは紹介しません。クラウドベンダー側の責任範囲としてOFを挙げていますが、「これはなんなのか？」と。クラウドベンダー側では、セキュリティが内部としてどうなっているかは残念ながら見れません。ただ、見れないからわからないのかというと、まったくそういうわけでもなく、いろんな方法があります。
まずユーザー側からクラウド上でのAPIをたどって、それで監査をするといった方法があります。これで、クラウドベンダー側で適切なセキュリティを実装しているかどうかというところも、がんばればできなくはないです。メインとしてお伝えしたいのは、いろんなクラウドベンダーでいろんなコンプライアンス、第三者認証を取っています。例えばISOだったりSOCといったコンプライアンスをとっています。
それを取ることによって、例えばスタートアップ企業がそのとある業界に関して、医療であればHIPAAというものがありますが、そういうところに関してわざわざ自分たちがセキュリティを強固に1から作り上げずに、クラウドベンダー側でその業界の最低ラインをクリアしたものを提供してくれると。こんないいことないですよねというところが、このSecurity OF Cloudのポイントです。
Security by Design
そしてSecurity by Designをよく言いますよね。Security by Designにおきまして、私釜山から3つの観点でご紹介させていただきます。アプリケーション開発、クラウドサービス、インフラストラクチャのそれぞれ視点が異なります。よくSecurity by Designと言いますが、人によって言ってることが違います。それぞれ間違っているわけではなく、視点が違えばセキュリティの実装方式も違うという話です。
アプリケーション開発でやることは、コードの中身です。あるいはそのアプリケーション自体に対するアクセス制御も含まれます。コードの分析の話であれば、SASTの静的分析、DASTの動的分析などが挙げられます。
そして1つ飛ばしてインフラストラクチャ。これは従来の考え方からそれほど難しい話ではないですね。変わりはないです。Bastionという踏み台サーバを入れる、適切なファイアウォールを実装する、IDS/IPSを実装する、不要なポートは閉じましょうなど一般的な話です。
最後にクラウドサービスです。先ほどご紹介させていただいたクラウド時代のクラウドベンダー側、あるいはセキュリティベンダー側が提供するサービスですよというところです。
そしてSecurity by Designの定義。ここはさらっと流しますけど、まずセキュリティにおいて、アプリケーションやプロダクトをローンチしてからセキュリティを実装しないといけない。「なんかどこぞの企業が漏えいしちゃった。何かやらないといけない」。そういうケースが多々あります。
それが必ずしもダメというわけではないんですけど、セキュリティは後になればなるほど継ぎ接ぎになってセキュリティリスクが発生する可能性があります。継ぎ接ぎになるということはセキュリティホールがどこかで発生するということを意味しています。そういう場合はどうしたらいいんだ！？
最初からやりましょうよという話です。最初からセキュリティを意識した上でのデザイン設計をすることによって、セキュリティホールが極めて少ない設計にできます。例えばここでIoT製品とか挙げられてますけれど、よくあるのが、開発のときに利便性を考慮してSSHではなくTELNETを使いますと。それはいいんですけど……いいのかな？ ちょっと微妙ですけど。
TELNETを使って、TELNETのポート23をそのまま放置。TELNETのサービスもそうですし、ポートをそのまま開放してそのままIoT製品を世に出す。こういった事例が多々あります。どうですかね？ 今の話だけでも、ちょっと怖いなと思いませんか？
クラウド・バイ・デフォルト
というところで、クラウド・バイ・デフォルト。このクラウド・バイ・デフォルトもけっこう重要な話で、システムを選定するにあたって、まずはクラウドを選定しましょう、クラウドを活用しましょうというのがクラウド・バイ・デフォルトです。具体的に書かれている『政府情報システムにおけるクラウドサービスの利用に係る基本方針』という長いドキュメントの基本方針のところに、クラウド・バイ・デフォルトが記載されています。
具体方針として、けっこう有用なことが書いてあるのでみなさんぜひともご覧いただきたいんですけど、1つ紹介させていただきます。具体方針では、ステップごとにどういうクラウドを扱うか、採用するかというのが記載されています。最初のステップとしては、パブリッククラウドにおけるSaaSを選定しましょうと書かれています。
そして次はパブリックではないけどプライベートクラウドにおけるSaaS。そしてやっとその次のタイミングでIaaS、PaaS領域についてのパブリッククラウドの採用が言われています。
例えばよく言われるのが、なんとなくクラウドを使いたいから、まずAWS使いましょう、Azure使いましょう、GCP使いましょう。よくあります。クラウド・バイ・デフォルトというのは、まずそういう方針にするのではなく、例えばOfficeであればOffice 365を使います。Salesforceを使います。ServiceNowを使いますといったように、SaaSから採用していきましょうよというのが、このクラウド・バイ・デフォルトの考え方です。これは押さえておくべきですね。
セキュリティ技術カテゴリー
そして最後にセキュリティ技術カテゴリー。ここも簡単に紹介しますと、1つモチーフとしているのが、クラウドセキュリティアライアンスのガイダンスです。ドメインが1から14まであります。前段のところは情報セキュリティポリシー、ガバナンスに関わるようなところで、技術要素としてはドメイン6以降です。この技術要素の部分を少し紹介します。
管理画面を死守する
ドメイン6の管理画面とGCPについて。あまり時間もないのでポイントだけご紹介しますと、クラウドと従来のオンプレミスでは、セキュリティは何が違うのか。 管理画面を先ほどご紹介させていただきましたが、管理コンソールのところのセキュリティというのを強固にする必要があります。 なぜか。管理コンソールを乗っ取られることによってすべての操作が可能になるからです。
さまざまなことができてしまうので、「EC2、Azure VMといったインスタンスのOSのパスワードをリセットする」、なんてことも簡単にできます。ですので管理画面を死守しましょう。MFAを採用するとかですね。
インフラストラクチャセキュリティ
ここはこれまでのオンプレミスの考え方と、ほとんど一緒ではあるんですけど、ワークロードですね。ワークロードの分離・隔離を必ずしましょうと。もちろんこれはクラウドベンダー側で、隔離は当然のことながらしているんですけど、利用者のほうでも利便性が高いがためにワークロードを一緒にしちゃうことがあります。そうすることによってふだん共有しちゃいけないデータを共有しちゃったり、そういうセキュリティ事故につながることがあります。
ドメイン仮想化とコンテナ技術
めっちゃ長いですね。飛ばします。コンテナに関しては、コンテナのイメージ自体の脆弱性が含まれていることがあるのでセキュリティチェックをしましょうというのが、最近のトレンドです。
アプリケーションセキュリティ
先ほどSAST、DASTといった言葉を紹介しました。単純にSASTとDASTだけをやるわけではなく、そもそもちゃんとコードレビューであったり、リグレッション機能テストというのを正しい流れでセキュリティを意識した上でやりましょうと。そして侵入テストですね。CI/CDとかもやりましょうと。
データセキュリティと暗号化
これは一番最初にもお話ししましたが、守りたいモノの定義をしましょう。データドリブンの考え方です。データストレージを適切なもので選択します。
オブジェクトストレージ。AWSだったらS3ですね。AzureだったらBlob Storageというものがありますけど、そういったオブジェクトストレージを採用する場合もあれば、そうではなくWindowsファイル共有サーバを採択するといったこと、Azure Filesとか、そういったものを選択するといったことも必要とされます。適材適所のデータの扱いですね。データ移行はがんばれよとか、いろいろあります。ストレージの暗号化に関してもこちらが考える必要があります。
鍵管理
そして鍵管理です。鍵管理につきまして、どこで管理するのかを適切に考える必要があります。クラウドネイティブとよく言われますよね。ただ、鍵管理に関しましては、クラウドにすべて預けるのは本当にいいのかというのを一度考える必要があります。もしその鍵自体がクラウドベンダー側で何かあったらどうしますかと。
といったところをクラウドセキュリティアライアンスでは、懸念事項の1つとして言われています。カントリーリスクの影響とかもありますね。
それからデータマスキングを正しくしましょう。開発とテスト環境、あるいはステージング環境ですべて同じデータでやりますか？ 必要であればやればいいです。必ずしもそれが適切ではないこともありますが。
アクセス管理
よくIdentity and Access Managementとか言われますよね。そういったものを適切に実装していきましょう。RBAC大事ですね、ABAC大事ですねという話です。
ちょっと最後は駆け足でしたけど、20分間お話させていただきました。みなさんいかがでしたでしょうか？データドリブンの発想であったり、そもそも最初にセキュリティを正しく実装するというマインドをご理解いただけましたでしょうか。20分間という短い時間でお伝えできることは限られていますが、私はもともとエンジニアだったということもあるので、今後は、技術の深いところの提供ができる日が来ればしようかなと思います。
では、釜山の発表は以上です。ありがとうございました。
