こんにちは、neige_gnomeです。
プライベートでは２児の母で、子どもに自宅の壁をボッコボコにされています。
会社では開発管理課という部署で、PSIRT(※)のようなことをやってます。
開発管理課は、開発部の中の１部署で、「エンジニアが働きやすい環境を提供し、成果の最大化に貢献する」をMissionに、当社の提供するサービス開発におかるセキュリティ・品質面のサポートを行っている部署です。
今回は、ラクスにおけるプロダクトセキュリティ対策について、私たちの活動内容をチョコっとだけご紹介します。
※PSIRTとは：製品(Product)レベルのセキュリティ担当者のことを意味します。
会社レベルのセキュリティ担当であるCSIRTよりもスコープが開発寄りな分、
開発に特化したセキュリティ対策を行う人とイメージいただければと思います。
はじめに
昨今、残念なことにマルウェアやフィッシング被害のインシデントニュースを聞かない日はありません。
自社サイトがマルウェアの発信源にされていた、という話も聞きます。
そんな状況の中で、私たちは攻撃者たちからどのように自社を守れば良いのでしょうか。
今回は我々(以下、PSIRT担当と記載)のコミットメントが大きい「OSSの脆弱性、EOL、ライセンスのチェック」に絞ってラクスの事例をご紹介します。
前提説明
本題の前に２点、ラクスの組織体制と、OSSについて説明を入れさせて頂きます。
何やってるかだけ知りたい人は飛ばして『本題』を見てくださいネ！
・ラクスの組織体制ご紹介
当社は企業の成長を支援するITサービスを提供する会社として、バックオフィス系のSaaSサービスを展開しています。
さて問題です。当社が公開しているSaaSサービスの数をご存じでしょうか。
楽楽精算、楽楽明細あたりはTV CMを御覧になった方も居ると思いますが、他にも沢山あるんです。
また、公開しているサービスだけではなく、より良いサービスを世に出すために日々研究や開発を重ねています。
詳しくはコチラ→クラウド事業 | 株式会社ラクス
そしてそれらのSaaSサービスを開発するには、プログラム言語をはじめとした開発知識だけではなく
関連法や、対象製品に対する深い理解が必要になります。
そのため、ラクスではサービスごとに専門の開発部隊が存在します。
しかも！ベスト・オブ・ブリードで開発を進める方針の都合上、
各サービスに最適な技術を取り入れているため、サービス間でシステム構成が異なります。
私たちPSIRT担当はそういった、人もシステム構成も異なる全サービス開発担当者に向けて、
横断的にセキュリティやライセンスの方針を作ったり、方針適用のサポートをしています。
・OSSとは
OSSは一般公開されているプログラムのことを言います。
サービス開発を家の建築に例えるなら、OSSは洗面台パーツやトイレパーツのようなものです。
パーツを持ってきて組み込むことで、トイレを自分で１から作るよりも、遥かに効率的に家を作ることが出来ますよね。
プログラムも同じです。
しかも有償の洗面台やトイレとは違い、OSSは特定の条件の基であれば無償で利用できるケースがあることが特徴です。凄いですよね。
そんな素敵なOSSですが、善意で公開されている性質上、開発の進みが遅かったり、EOL(=開発がストップ)する可能性もあります。
酷いケースだと、明らかに大きな脆弱性(=セキュリティ的な不具合)があっても、放置され続ける場合もあります。
更に、毎日新しいパターンの脆弱性が発見されているため、いま脆弱性の無いOSSでも明日にはどうなるか分かりません。
そういった新しい脆弱性を持つOSSや、EOLしたOSSはクラッカーたちの格好の攻撃ターゲットになります。
つまり、OSSを安心して使い続けるには、OSSがEOLしたり脆弱性が発生していないかを、コンスタントにチェックして対応する力が必要になるのです。
勿論、ラクスでも数百にも上るOSSを利用していますので、継続的に監視・対応しています。
なお、OSSは"特定の条件の基であれば"無償で利用できると書きましたが、
その"特定の条件"というのが、"ライセンスと利用条件"です。
特にライセンスは、よくあるライセンスだけでも600以上の種類があり、それぞれでどんな利用方法がOK/NGなのかが異なります。
独自のライセンスを持つOSSも多いため、使いたいOSSが本当に使えるのかを確実にチェックすることが重要です。
ラクスでは、NGな利用方法をしないよう、PSIRT担当がチェックしています。
本題
さてここでは、ラクスにおけるOSSのライセンス、脆弱性、EOLのチェックのながれをご紹介します。
主な登場人物は、PSIRT担当とサービス開発担当の２者です。
①ライセンスチェックのながれ：
となっています。
新出パターンのライセンスが出てきた場合は、このフローに法務担当部署が加わり、PSIRT担当と認識をすりあわせます。
②脆弱性チェックのながれ：
となっています。
サービス開発担当は、対応方針を決めたら開発・PSIRT担当全体に共有しますが、
その際『対応方針を決めるのは通知から最遅でもX時間以内、
クリティカルな脆弱性があった場合にOSSのアップデートを適用した製品をリリースするのはX日以内』
というラクス独自のルールに従います。細かい数字はセキュリティに影響するため言えませんが、
Xに入る数字は相当短い、とだけ書かせて頂きます。(サービス開発担当者の技術力が伺えますね。)
なおPSIRT担当の情報収集源は多岐にわたります。
商用ツールだけでなく、脆弱性の一覧サイト(NVD, JVN)、Apacheなどベンダーのサイト、RSSフィードから直接拾うこともあります。
ツールも利用していますが、機械チェックでは誤検知が多いため、人の目である程度フィルタリングした後にサービス開発担当へ通知するようにしています。
(実はこの部分に、PSIRT担当・サービス開発担当の双方が少し前まで多大な工数をかけていました。
それを先日自動化し、年間数百時間の工数削減に成功しました★そのお話はまた後日。)
③EOLチェックのながれ：
脆弱性チェックと同じですので、図は割愛させていただきます。
PSIRT担当がEOLの情報収集をする上でトリッキーなポイントがあります。
実はEOL予定というものは、OSSの公開ページに直接記載されているものから一切書かれていないものまで、様々です。
そこで、ラクスでは独自に『X年以上開発がストップしているOSSはEOLと見做す』という基準を設けて、
EOL予定が近いOSSを定期的にリストアップし開発へ通知しています。
サービス開発担当は、EOLが来る時期を見据えて別のOSSに乗り換えたり、小さい機能であれば自社開発するなどして備えます。
以上が、ラクスにおけるOSSのライセンス、脆弱性、EOLのチェック体制です。
ちなみに上記３つの体制において、当社では情報共有に当社製品『楽楽販売』を利用しています。
楽楽販売はAPI対応、ノーコードで色々な処理が自動化できて、承認プロセスもケアできる便利なツールです。
ご利用・ご検討頂いてるお客様へCRM以外にもご活用頂けますよ、ということでご紹介させていただきました。
今後の課題
ここまで、当社のライセンス・脆弱性・EOL管理についてご紹介してきましたが、
我々もPSIRT担当として他社の例に漏れず、課題を抱えています。
個人的に大きいと思っている課題を３点を挙げてみました。
課題その１．人力対応が多い
文中にも若干記載した通り、自動化は適宜進めていますが
まだまだ手動の箇所が多く、PSIRT担当として生産的な活動に廻せるリソースが少ない状況です。
そのため、品質は担保したまま、ツールなどを活用しライセンスチェック～脆弱性検知をトータルで効率化できないか検討中です。
課題その２．ステークホルダが可変式
セキュリティルールの策定・変更に対して、10以上の関連組織(総勢300名～)に100%コンセンサスを得るのは無理です。
かといって運用との乖離は出したくないので、ある程度はネゴりたいところです。
しかしながら、要件次第でどの組織の誰に訊けば情報があるのか/誰に承認貰えば良いかが変わるため、
いろいろな現場で相異なるご意見をいただいた場合は、方針を取り纏めるのに苦労することもあります。
(もういっそ開き直って、分かる範囲で調整した上でサッサとルールを全体周知してしまい、
指摘を受ければ即是正する方が当社の変化のスピード感に合っているかも・・と思っています。)
課題その３．ウォッチすべき技術領域が広がりすぎ
その時々で理想とされるシステム構成や世間のニーズに追随するため、ラクスのサービスで扱う技術領域は日々広がっています。
古き良きオンプレのファイルシステム、クラウド、モバイルアプリ、Dockerと、セキュリティ面でカバーすべき範囲もその都度広がってきました。
各技術に共通するセキュリティルールは多いものの、新技術独自のルールも整備していく必要があります。
ただ、新しくルールを作るとしてそれをチェックできる体制を敷かねばなりません。
その一方で、新技術の確立で陳腐化してしまったルールがあれば、早急に改善する必要があります。
こういった技術トレンドの変化に全てオンタイムでルールを整備するのは厳しいものがあります。
特に、多数のサービス開発者にコンセンサスを得る場合は余計に時間がかかります。
優先度を決めて順次対応していますが、それまでは個別に問合せや連絡対応をする必要がありサービス開発担当の方に申し訳なく思っています。
生成系AIと少しのコーディングで、そういったルールのアップデートやネゴシエーションを
大幅に自動化できるのではないかと妄想はしていますが、今はまだ、手を出せていません。
さいごに
セキュリティ対策は、サービス開発効率とのトレードオフの側面があります。
やり過ぎた結果、開発効率やサービスレベルを下げてしまうのは可能な限り避けるべきです。
とはいえ、セキュリティインシデントのニュースは増える一方ですので、MAXに警戒する必要があります。
それを踏まえて、私たち開発管理課は、サービス開発担当との情報共有を密に行い、時流と事業規模に合った標準化/方針策定をすることで、自社に最適なセキュリティ強化を図っていきたいと思っています。
と、真面目なことをつらつらと書きましたが、現場では毎日、和気あいあいと改善に向けて取り組んでいます。
特に、失敗があっても許容してくれる社風のお陰で気楽にトライ&エラーが出来て助かっています。
チャレンジとお喋りと勉強が好きな方、いつでもお待ちしています。
★開発管理課では一緒に働くメンバーを募集してます！！★
↓ ↓ ↓
プロダクトセキュリティエンジニア の項をご参照願います。
募集職種 | 株式会社ラクス キャリア採用
