技術分野は成熟が進み、新しい領域が急激に増えています。本コーナーでは技術へのタッチポイントを増やすことを目標に、各分野で活躍されている方をお迎えします。
今回はエンジニアなら誰もが気にかけるセキュリティ分野で活躍されている鈴木さんにリスクとの付き合い方を学びます。
【話し手】
鈴木研吾 SUZUKI Kengo
鈴木研吾 SUZUKI Kengo
証券会社向けのManaged Security Serviceに従事した後、Fintech系スタートアップにてインフラのセキュリティを担当。セキュリティキャンプ全国大会の講師やセキュリティ系同人サークル
Twitter @ken5scal
GitHub ken5scal
身近な脅威
日高： セキュリティはIT業界でも重要なテーマの一つですが、どのような経緯で携わるようになったのでしょうか。
鈴木： きっかけは新卒でセキュリティベンダーに入ったことです。そのあとフィンテック業界を経験し、今の所属企業でもセキュリティやインフラ、社内基盤など幅広く担当しています。
日高： はじめからセキュリティに興味があったのですか？
鈴木： インターン先でたまたまセキュリティ部門に配属されて、そのまま就職につながったという経緯です。学生のころにPlayStation Networkのハッキングが話題になって印象に残っていたというのもきっかけの一つです。
日高： それはセキュリティを身近に感じる話題だ。
鈴木： 当時、通っていた大学の学生向け保険で個人情報が流出してしまう出来事がありました。情報漏洩発生時の
日高： 起きてほしくないですが情報漏洩のニュースは今も頻繁に見聞きします。
鈴木： はい。セキュリティへの関心という世の中の流れと自分の体験がカチッとはまったのがモチベーションだったのかなと思います。
日高： ここ数年、重要度が高まっていると個人的にも感じています。
鈴木： 昔、セキュリティの業務をしていると言ったら警備員だと勘違いされたことがあるんですよね。今は認知が進んでセキュリティエンジニアが身近な存在になっているんじゃないかな。
日高： 一般に知ってもらえるぐらい、情報漏洩事例が多いとも言えるかも。
鈴木： 転機はベネッセの個人情報流出事件だったと思います。誰もが知っている企業で起きて注目が集まって、そのほかの事例が積み重なっていった結果かもしれません。
日高： たしかに私も印象に残っています。
鈴木： 社会的認知の高い暗号資産取引所やコンビニチェーンなどの大きなサービスでも情報漏洩がありましたし、一般社会からも企業にセキュリティリスクへの対策が求められはじめました。
リスクとの付き合い方
日高： ソフトウェアエンジニアも個人情報保護の研修を受けることがあります。
鈴木： 企業活動の中で、特にビジネス開発やカスタマーサポートの方々は個人情報に触れることがあります。ただし一部だけでなく全員がしっかりと個人情報を理解する必要があります。
日高： セキュリティ対策をやりきるのって大変ですよね。
鈴木： 世の中には対策方法がまとめられています。どんな対策があるのか理解し、ルールを整理して、きちんと実施していくことが重要です。
日高： 我々だとアプリケーションのソフトウェア設計、データベースなどのアクセス権、サーバのAPIなど業務に関わるところでセキュリティの知識が必要です。
鈴木： いわゆるプロダクトセキュリティですね。Software is eating The WorldやEmbedded xxxな世界では、プロダクトソフトウェアも組織のセキュリティポリシーの対象とし、文書化して、事業の実態にあわせて一貫性や実効性を維持するようなガバナンスがないときちんと支えにくいです。
日高： 実際の対策は地味な作業も多いですが、インシデントって何も起きないのが一番かなと。
鈴木： 私もセキュリティエンジニアとして難しさを感じていて、自分ができているのか自問自答しますね。
日高： 先ほどのセキュリティポリシーも重要なのはわかりますが、やはり実際にやれることは工数など実情も影響するし、どこかに限界がある。
鈴木： 優先順位を考えて対策したとして
日高： 何でもできるわけじゃないので、どこにラインを引くかですよね。結局は対話して決めざるを得ない。
鈴木： そうなんです。理想を言えばCISO
日高： セキュリティアセスメントを通じてリスクを可視化していくと。
鈴木： いずれにしても
インシデントのトレンド
日高： 対策が必要なインシデントにもトレンドがあるんでしょうか。
鈴木： YesでもありNoでもあると思います。攻撃側からすると狙う場所っていう意味でのトレンドはあるんですが、防御側ではトレンドというより基本的なところが多いです。
日高： 立場によって異なると。
鈴木： サプライチェーン攻撃という手法では、攻撃者の狙いはプロダクトを作る事業者が使いそうなサービス、たとえばCI/
日高： 最近よく聞く話題です。
鈴木： プロダクトをリリースするうえで必ず使うため、そこに情報の価値が集約されているとも言えますし、同時に単一障害点でもあります。
日高： 格好の標的になってしまっている。
鈴木： このような開発フローはどこの会社でも普及していますし、じゃあ狙ってみようという発想ですね。
日高： クラウドサービスでのソフトウェア開発が活発になっている現代だからこそだなぁ。ソースコード管理のGitも本来は分散して開発するしくみのはずですが、GitHub上でのコラボレーションが中心になってしまった結果、使えないと困ってしまう。
鈴木： そういったクラウドネイティブなプロダクトのサプライチェーンを狙ったり、あとはLastPassのようなパスワードマネージャやSSO
日高： 特定の脆弱性が狙われるだけではないと？
鈴木： はい。たとえば社内に侵入する目的で従業員個人のメールアドレスへフィッシング攻撃がしかけられた結果、私用なパソコンでログインしていたエンジニアを経由して認証済みセッションを盗み出されるとかです。ブラウザに対する攻撃は新しいものではありません。
日高： それこそ研修で習う基礎的な話に行き着く。
鈴木： この例では自社の端末以外からはアクセスさせないとかブラウザやOSのパッチ適用をするといったベストプラクティスで防ぐというのが理想です。
日高： ええ、守る側の視点だとトレンドといった目新しさではなくて基本を忠実にこなすことが大事なんですね。
鈴木： このあたりは理想論というか、ちゃんと基礎をやりきる難しさも示しています。
組織の内側と外側
日高： 私用なパソコンを業務で使わないという原則は頭では理解できている一方、誰かがやってしまうという疑いは払拭しにくい気がします。大きな組織ほど難しくなりそうというか。
鈴木： そうです。極論、全員に社用パソコンを使えと制限したら私用パソコンで使われるリスクはゼロになります。しかしこれで十分とも限らないんです。この前、ニュースで知った事例なのですが、どこかの大学では二要素認証を義務付けられていたんですが、名誉教授の方が例外だったんです。
日高： そこから漏れてしまったんですか。
鈴木： この場合は、例外をカバーしきれなかったケースですね。これって二要素認証がベストプラクティスだという認知があり、運用もされていたにもかかわらず起きています。基本的なことをちゃんとやる難しさが現れている事例だなぁと。
日高： 例外を作らないなら簡単そうに聞こえますが、きっと会社組織が硬直しますよね。業務フローに合っていないルールは守られない気もします。
鈴木： その会社で活動する際、業務委託や外部監査の方など組織の内側と外側、両方の性質を併せ持つことがあります。このようなケースでは例外にせざるを得ない場合がまれにでてくるんです。
日高： グラデーションがある中でのセキュリティルール運用は大変ですね。
鈴木： ですのでベストプラクティスはあるけど、実際は生モノという肌感覚があります。
日高： ケースバイケースで自社基準をクリアしていくと。
鈴木： そうですね。ケースバイケースというと何も回答できていないんじゃないかと不安になりますが、結局のところ会社や事業と向き合って対話を重ねていく地道な活動なのかなと。
日高： 実際に起こり得る流出経路は攻撃を受けるだけじゃなくて、単純なうっかりミスとかもありますし、特定のルールだけ厳しくても守れない。
鈴木： いろんなケースがありますよ。顧客が便利に使おうとした結果、たまたま想定外の利用方法を見つけて、それがセキュリティ上よくないという場合もあるでしょうし、従業員が楽をしようとした結果、権限が適切でなかった場合や、もっというと内部に攻撃者がいたという脅威もあります。
日高： いずれかのケースで情報が漏れてしまった場合にリスクが顕在化してインシデントとして扱われる。
ソフトウェア資産を守る
日高： ソフトウェアの観点、いわゆる情報セキュリティの分野ではどうでしょうか。
鈴木： 最近だとサプライチェーンへの攻撃がトレンドになりつつあるという話をしましたが、いかにAPIキーを守るかっていう点に注目しています。
日高： APIキーやアクセストークンの流出事例は裏を返すとAPI利用が進んで一般化した結果ですよね。
鈴木： 認証・
日高： ある種の権限を持っていますよね。
鈴木： そのあたりをどう守るかが今後考えられていくでしょうね。認証済みのセッションを盗まれないように守ったり、ソースコードの中で安全にAPIキーを取り扱ったりですね。
日高： APIキーやアクセストークンをハードコードすると漏れてしまう。
鈴木： ログイン観点では OpenID ConnectやクラウドサービスのCLI
日高： 有効期限を短くしたりとリスクを小さくはできるけど、果たしてそれで十分かというと私にはわからないです。
鈴木： APIやクラウドサービスの利用が進んだからこその課題です。
日高： 現代のソフトウェアを見ていると自由度が高くなったと感じます。できることが広がっているわけですし。
鈴木： その自由度の高さ、実装できる裾の広さが生まれたのは最近の出来事ですし、連携が当たり前になった場合、ソフトウェアにどんなリスクがあって顕在化するのかは今後も注目していきたいトピックです。APIキーってユーザーの権限をソフトウェアに委譲している側面もあります。
日高： 特定のページが読み取られましたという限定的な流出ではなくて、あらゆる行動が取られる可能性がありますよね、APIキーの持つ権限が広いと。
鈴木： 今後も狙われ続けるんだろうなと思いますし、過去あったLog4jの事件をきっかけに、この2年ぐらいはソフトウェアサプライチェーンを守ろうという動きも活発になっています。
セキュリティエンジニアの役割
日高： お話をうかがっていると個人や組織で考えるべきことが本当に多いですね。ベストプラクティスがあるといってもそのまま適用して終わりでもない。
鈴木： 1人で決められないこともあるので、きちんと言語化してコミュニケーションをとらなきゃというシーンもあります。
日高： 提案するにも社内事例がない場合もあるのでは。そういうときは苦労しそうです。
鈴木： 情報収集という点では個人的な活動をしていて、セキュリティをテーマにしたPodcastやニュースを定期的に配信しています。あとオライリー・
日高： インプットとアウトプットを兼ねているわけですね。
鈴木： そうですね。頭を捻って話すことで言語化のレベルを上げているという意味では自分のメリットも大きいですが、私と同じような立場の方に情報が届いて議論のきっかけになればと思います。
日高： 報道があったときにだけ盛り上がっていても疲れますし、恒常的に意識したいですよね。KPI
鈴木： セキュリティを定量化する指標ってあんまりないと感じています。インシデントに対応しているだけでは
日高： セキュリティ担当者だけじゃなくて組織で考える。
鈴木： コミットメントが形成されることで自分たちがベストを選んだという自信につながっていくと思うんですよね。プロセスを肯定的にとらえて、次の組織固めに進めるんじゃないかと感じています。
日高： セキュリティでは誰もが当事者といえますね。
鈴木： 守るだけじゃなくてセキュリティでも攻めて事前にリスクを潰すこともできますし、事業を成長させるセキュリティエンジニアでありたいです。
日高： わかりやすいお話ありがとうございました。