情報セキュリティエンジニア

応募要項

セキュリティーエンジニア

 

カジュアル面談

Sansan技術本部では中途採用向けにカジュアル面談を実施しています。各プロダクトの開発チームの業務内容ややりがいを現役エンジニアの視点からお話します。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
 

Pick Up コンテンツ

情報セキュリティ部長が描く、 Sansanのセキュリティ・バイ・デザイン構想

Sansan株式会社の情報セキュリティ部門は今、会社の拡大に合わせてさらなる成長を求められています。そこで目指すのが、セキュリティ・バイ・デザイン。これはプロダクトの企画・設計の段階からセキュリティ対策を組み込んで脆弱性の発生を未然に防ぎ、不正ができないセキュアな状態を保つ状態を指します。その実現のために、今何が課題で、解決に向けてどんな構想を練っているのか、部長の竹脇に話を聞きました。
続きを読む

Sansanの情報セキュリティ部は 事業成長を止めない「ガードレール」

Sansanで情報セキュリティを専門に扱う組織が最初に立ち上がったのは2015年。当時CSIRT（Computer Security Incident Response Team）だったこの組織は、会社の変化に合わせて役割を拡大し、進化し続けています。今回はCSIRTを立ち上げ、現在は情報セキュリティ部門のマネジャーとして組織を統括する河村辰也に、情報セキュリティのあり方、そして目指す進化の形について聞きました。 続きを読む

アプリ開発とQAエンジニアの経験を強みに、 事業成長を支えるセキュリティをリード

情報セキュリティ部門に新設されたプロダクトセキュリティチーム。セキュリティ・バイ・デザインの実現を目指すこのチームには、高いリスク感度と嗅覚でプロダクト開発とセキュリティの橋渡し役を担うエンジニアが集結しています。今回話を聞いたのは、その中でも異色のキャリアの持ち主、黒澤綾香です。エンジニアとして多様な経験を積んできた黒澤が、今セキュリティ部門で感じている業務のやりがい、そして今後の展望について語りました。 続きを読む

CSIRTとして挑戦しがいのある 「セキュリティと利便性の両立」とは

Sansan株式会社の情報セキュリティ部のCSIRTグループで働く佐藤健太にインタビューを行いました。ベンダーから転職の決め手になったのは、Sansan株式会社がSansanのカタチの中でPremiseとして掲げている「セキュリティと利便性の両立」への挑戦。日々、そこにどのように向き合い、取り組んでいるのかを聞きました。 続きを読む
 

「この領域ならば、あの人」と言われるような、 明確な強みを持つエンジニアになりたい

技術本部 CSIRTグループ　吉山 遼太

Sansan 株式会社に新卒として入社。入社後は CSIRT の SOC チームメンバーとして、新規サービスの診断や社員からの問い合わせの対応などを行う。現在は、全社統合ログ基盤の構築と運用に携わり、ログの集約に向き合っている。
ソフトウェア開発においては、機能を増やして利便性を高める“攻め”の技術だけではなく、セキュリティを堅牢にしてサービスと会社の信頼性を高める“守り”の技術も重要です。Sansan株式会社において、セキュリティ対策を担う組織が「CSIRT」。このチームは顧客の個人情報の安全性担保を重視するだけではなく、生産性や業務効率を下げないセキュリティ対策を目指しています。CSIRTの吉山遼太に話を聞きました。
続きを見る

緊張感と責任感が伴い、大きなやりがいを得られる仕事

私は高等専門学校の出身で、当時からセキュリティの技術に興味を持ち、SECCONというセキュリティ系のイベントにも参加していました。Sansanに興味を持ったきっかけは、就職活動時にエンジニアの方々と話をしたことです。
Sansanの企業理念「Sansanのカタチ」にあるPremise（前提、という意味）には「セキュリティと利便性を両立させる」というメッセージが掲げられています。このフレーズが示すように、Sansanはセキュリティ向上に非常に力を入れています。そのマインドがエンジニアの方々からひしひしと伝わってきたことから、「この会社でセキュリティのことをより深く学んでみたい」と思うようになり、入社を決めました。
CSIRTとして実務に携わると、高等専門学校時代にコンテストのために取り組んでいたエンジニアリングとは、まるで別物だなと感じました。緊張感と責任感が伴い、大きなやりがいを得られます。
求められるのはセキュリティ関連のスキルだけではありません。CSIRT以外のチームとも連携しながらプロジェクトを進めるため、調整力や巻き込み力、ステークホルダーとのコミュニケーションスキルなども必要です。そして、業務においてとても重要なのが想像力を働かせることです。

CSIRTで働いたからこそ、価値観が変化した

私は今、全社横断の統合的なログ基盤を構築するプロジェクトを担当しています。このプロジェクトの目的は、社内で開発・運用されている全サービスのログやメンバーの作業内容のログなどを収集し、検索しやすい状態にすること。これにより、Sansan社内で行われているありとあらゆる作業内容を追跡可能にして、セキュリティを向上させます。
このプロジェクトの推進は、難易度が非常に高いです。長期にわたるプロジェクトになりますから、プランニングの力が求められます。目的を達成するためには、大がかりなアーキテクチャ設計や各種の調査・検証が必要です。
また、社内の全部署とも連携を取り、アプリケーションの仕様も調べながら推進していくことになり、挑みがいのあるプロジェクトです。この業務をやりきることで、Sansanのセキュリティがさらに向上し、自分自身のスキル向上にも結びつくと思っています。
かつて私は「幅広い領域のスキルを持ったエンジニアになりたい」と思っていました。ですが、今はどちらかというと、その逆。特定のスキルをもっと深掘りしたいと考えています。具体的には分析力ですかね。将来的には「あの分野ならば、吉山が強い」と言ってもらえるくらいに、専門性の高いエンジニアを目指したいです。
こう思えるようになったのも、Sansan-CSIRTで働いたからこそです。Sansan-CSIRTのエンジニアは、幅広い領域のスキルを身につけつつも、おのおのが何かの領域で突出した力を持っています。自分も彼らのように、明確な強みを持ちたいと思っています。
 
 
オフィスについて
業務環境・社内制度について
 

グループ概要

CSIRTのメンバーたちは、堅牢にするだけのセキュリティ対策には意味がないと考えています。

Sansan株式会社の企業理念である「Sansanのカタチ」には、Premiseとして「セキュリティと利便性を両立させる」という言葉が記されています。このフレーズが示すように、私たちは創業以来、個人情報などの大切なデータを守る方法を考え続けてきました。
そんなSansanのマインドを体現するチームがCSIRT。「Computer Security Incident Response Team」の略称であるこの組織は、社内のありとあらゆるセキュリティ課題への対応を担っています。
もっと見る
また、Sansanはセキュリティタスクフォースという、各プロダクトの開発部門や社内システムの管理部門のエンジニアが所属する仮想的な組織を設けています。CSIRTとセキュリティタスクフォースとCISO（Chief Information Security Officer：最高情報セキュリティ責任者）とが連携して情報を共有しながら、Sansanのセキュリティについて各種の取り組みを続けています。
CSIRTのメンバーたちは、堅牢にするだけのセキュリティ対策には意味がないと考えています。Sansanでは大勢の社員が働いているため、いくら堅牢でも、彼らの業務に制約が生じるようなセキュリティ対策では、企業全体の生産性は向上しません。各種の脅威からシステムやデータを守りつつも、社員たちは自由度高く業務に取り組める。私たちCSIRTは、そんな状態を目指しています。
CSIRTには「テクノロジーだけではすべての事象を検知・対応しきれない。だからこそ、人間の判断力や思考力、察知力が必要になる」という考え方があります。だからメンバー一人ひとりが、社内のステークホルダーと適切にコミュニケーションをとり、必要な情報を拾い上げる。そして、発生している事象から“本質的な課題”を見抜き、実行すべき施策を決定します。
CSIRTのメンバーに求められるスキルは多岐にわたります。セキュリティの理解だけではなく、コミュニケーションスキルやアプリケーション仕様を理解するスキル、プロジェクトの推進・調整能力、そして分析力や決断力。例えるなら、エンジニアリングの総合格闘技のような仕事なのです。
Sansanのお客さまや取引先の方々、そして全社員が安心してシステムを利用できるように。私たちは、そのための土台作りを日々続けています。
 
 

「CSIRT」技術スタック

CategoryTechnology Stack
Programming Language / Library etc.Python, Ruby, JavaScript
Endpoint ProtectionCrowdStrike, Proofpoint
Authentication ProtocolsCAT, TestRail
Vulnerability AssessmentBurpSuite, OWASPZAP, Vaddy, FutureVuls
OSINT etcTwitter, Shodan, Censys, ThreatCrowd, SecurityTrails, Pentest-Tools, RiskIQ
Basic AnalysisNmap, Wireshark, ANY.RUN, HybridAnalysis, VirusTotal
Log AnalysisOpenSearch, Elasticsearch, Beats, Fluentd, rsyslog
InfrastructureAWS, GCP, Azure
MonitoringGrafana, Zabbix, CloudWatch
CIAWS CodePipeline
Code ManagementGitHub

「CSIRT」エンジニアに関する記事

Amazon Elasticsearch Service を用いた SIEM の構築事例 - Sansan Builders Blog
Sansan-CSIRTの松田です。Sansan に join してから早1年半が経過しました。 先日 AWS Security Roadshow Japan 2020 に「Sansanの成長を支えるセキュリティログの活用と Amazon Elasticsearch Service」をテーマに発表させて頂きました。 こんなに大きなイベントでの登壇は人生初です。しかもAWSです。それはもう緊張しました。開催報告は こちら に記載されていますので、興味のある方はウォッチしてみてください。 また、今回 CSIRT が開発に参画した SIEM on Amazon ES に関するリリースは以下に掲載されています。 時間の関係上、基本的なトピックしかお話できませんでしたので、本ブログではもう少し詳細に書きます。 発表内容でも触れましたが、一般的にSIEM（Security Information and Event Management）の機能としては以下の3つです。 SIEM に最も重点を置くことは、複数のログを管理し長期的に相関分析できる状態とすることです。 なぜなら Sansan は個人情報を扱う会社です。何も起きないように日々高いレベルで対策を実施し、運用しています。 しかしながら、組織を標的とした攻撃というものは用意周到に準備されるものであり、最終的には"いつもと違う"という違和感に気付くことで発見を早めることができます。 その点、違和感という物は簡単にロジックへ落とし込めない物が多く、まだまだ攻撃者が有利な状況が続いていることも理解しています。 だからと言って何もしないと言う訳にはいきません。 違和感に気付く、即ち「インシデントを発見して管理すること」を最終的な目的とするならば、その前提に必要となるログを管理しいつでも検索できる状態を目指すことになります。 ログを管理して、検索できる状態にするという行為は一見簡単そうに見えますが正直辛いです。地味な割には、手間がかかり、いざという時に無いと困るものです。 この当たり前のことをしっかりと実現するために今回 Amazon Elasticsearch Service （以下、Amazon ES）を選択したことは非常に良い決断だったと思っています。 以前は Splunk という製品を利用していましたが、維持運用にかかるコストが増加しつつありました。
https://buildersbox.corp-sansan.com/entry/2020/11/30/110000
全社統合ログ基盤を構築して得た知見 - Sansan Builders Blog
こんにちは。CSIRT の吉山です。 私は2020年の4月にセキュリティエンジニアとして新卒入社し、現在は主にログ基盤（SIEM）の構築・運用やインシデント対応などの業務に取り組んでいます。 今回はそのログ基盤構築や運用、その他検証で得た知見などについて紹介します。 まず初めにログ基盤の技術的な概要についてここで簡単に触れておきます。 ちなみに基盤構築の背景などについては、以前に同じく CSIRTの松田が記事にしているのでこちらもぜひ一読いただければと思います！ buildersbox.corp-sansan.com 基盤は AWS 上で構築しており、Amazon OpenSearch Service (以下、OpenSearch。旧 AWS Elasticsearch Service) をメインに構築しています。 基盤全体を見ると構成としては以下のような状態です。 ログの流れとしては S3 へのログの収集 S3 へのオブジェクト配置（PUT イベント）で ETL 用 Lambda (es-loader) をキック es-loader から OpenSearch へログをポスト という具合になっています。 ログ基盤へ取り込みたいログはすべて S3 へ保存しています。S3 から OpenSearch までは es-loader が一括して行っているため、S3 に保存さえすれば勝手にログがインデックスされます。 構成でも触れたとおり、ログ基盤へ取り込むログはすべて1度 S3 を経由します。 S3 を選んだ理由としては主に以下の3点があります。 コスト
https://buildersbox.corp-sansan.com/entry/2021/10/21/110000

当社エンジニアに関する記事

 

Sansan株式会社について

 
 

Sansan Tech Podcast

当社のエンジニアがお届けするPodcastです。Sansanエンジニアの技術のこと、カルチャーのこと、日々のSansanライフについて自由に語っています。