アーカイブ動画

ISIDが行っているセキュリティレビューとは

電通国際情報サービス Xイノベーション本部 アドバンストテクノロジー部 富田 聡氏

最初に登壇した富田氏は、セキュリティに関する研究開発、およびその成果を元にシステム開発のセキュリティ推進に従事している。「セキュリティチームによる部門横断型セキュリティレビューの事例」について、セッションを行った。

現在のシステム開発を取り巻くセキュリティ概況は、顧客情報の漏えい、機密情報の窃取、ランサムウェアによる脅迫など、被害報告が後を絶たず、攻撃は高度化・巧妙化している。そのため、セキュリティ確保の要求は日々高まっている。

だが、システム開発に目を向けると、開発チームが脅威とその対策方法を個別に調査するのには限界がある。そこで必要になるのがセキュリティ専門のチームによる調査・検証で得た知見の蓄積と展開だ。

知見の展開では、全社的に部門横断で進めることが欠かせない。そこでISIDではセキュリティレビューを行っている。セキュリティレビューとは、専門チームによる部門横断のレビューの仕組みである。

「各事業部のリスク管理プロセスに組込まれており、セキュリティレビューのルール化ができています」（富田氏）

目的は、システム開発・運用におけるセキュリティリスクを低減すること。インターネット接続案件すべてがセキュリティレビューの対象で、案件の中には、受託開発や自社の製品とサービスも含まれている。

ISIDがセキュリティレビューの骨組みを作り、プロセスを策定したのは2001年。2002年にセキュリティレビューを開始したという。

「まずは提案と設計レビューから始め、2008年に脆弱性検査を用意。その後も改善、強化をしながら現在に至っています」（富田氏）

現在は企画提案フェーズでは提案レビュー、要件定義・設計フェーズでは設計レビュー、実装、テストフェーズでは脆弱性検査（静的、動的）を組み込んでいる。（※補足：静的検査は、事業部においてリスクが高いと判断した案件等で実施する）

例えば提案時のレビューでは、提案予定のシステム構成案を見せてもらい、RFPや要求仕様書に記載されているセキュリティ要求に対応しているか、ヒアリング形式で確認し、レビュー結果報告書を提出する。

設計レビューでは、設計がセキュリティ要件に対応できているか、案件概要や非機能要件定義書、基本設計書、およびセキュリティチームが用意したチェックシートをベースに確認。対策方針が適切であることを確認する。

「重要ポイントはセキュリティチームで事前検討会を実施し、簡易的なリスク分析とベースラインアプローチの組み合わせで検討を行っています」（富田氏）

簡易的なリスク分析とは保護する情報資産を確認し、その資産に到達ルートから脅威と想定されるリスクを確認すること。ベースラインアプローチとは、セキュリティ対策チェックシートへの回答内容を確認することである。この2つの組み合わせで検討をし、開発チームと対面してレビュー会を行っている。

脆弱性検査ツールは、静的検査は『Fortify Static Code Analyzer』、動的検査は『AppScan Standard』を使用しているという。脆弱性検査ではツールの結果画面を参照しながら、レビュー会を実施している。

レビューはセキュリティ全般とシステム開発の知識を持つ専門家と、システムアーキテクチャとセキュアコーディングの知識を持つアーキテクトによるチームで実践している。

セキュリティレビューも大きく変化している

富田氏が、参加者にセキュリティレビューの変化で感じていることは何かと投げかけたところ、「そのときの攻撃手法の流行」「IoT機器など対象となる機器」「新しい脅威に対する対策も変わってきているのでは」「AWSなどのクラウド環境設定などのチェック」「レビュー時に使用するツール」などの回答が寄せられた。

それらに対し、「大きく変わったのはレビューの題材」と富田氏は指摘する。脅威や対策方法、システムアーキテクチャ、クラウドサービスも日々進化し、要素技術、開発手法、セキュリティ関連の法制度、ガイドラインが変わっている。

これらをキャッチアップするため、幅広い分野の調査、知見の蓄積が必要で、日々研鑽していかねばならない。もちろん、セキュリティ対策チェックシートも変えていく。

セキュリティレビューにおける苦労・課題

セキュリティレビューを進めるときにはさまざまな工夫、苦労がある。まず第一に、「計画段階ではセキュリティ要件が不明確」なケース。

事前の対策としては、IPAの「非機能要求グレード」や「安全なウェブサイトの作り方」、JNSA・OWASP Japanの「Webシステム/Webアプリケーションセキュリティ要件書」などの資料を参考にセキュリティ要件を明確にすることだ。第二が「設計レビューでは問題なしだが、テスト段階で問題が検知される」というケースである。

「ISIDは、セキュリティチームが作ったセキュアなWebアプリケーション実装ガイドを開発チームに使ってもらい、脆弱性検査を実施することで対応している」（富田氏）

第三のケースが「プロフィットセンターとコストセンターの対立が生まれること」。レビュイーがプロフィットセンター（事業部）の開発チームで、レビュアーはコストセンター（本部）のセキュリティチーム。開発チームは「直接的に利益を出しているのは自分たちだ」という意識がある。

こうした対立に対し、「ISIDでは問題の指摘と対応案をセットで当事者意識を持って伝えるようにしている」と富田氏。

セキュリティ確保の要求が強まっている状況において、システム開発ではセキュリティチームによる知見の蓄積と展開は必要不可欠となっている。その知見展開の方法の1つがセキュリティレビューである。

「今後もセキュリティの知見を蓄積し、部門横断で展開することで、システム開発・運用のセキュリティを推進していく」 富田氏は最後に力強く語り、セッションを締めた。

SaaSが抱える課題はSSOで解決できるのか

電通国際情報サービス　Xイノベーション本部 アドバンストテクノロジー部 佐藤 太一氏

続いて登壇した佐藤氏は、「現代的なアプローチでセキュアなアプリケーションを作る」ことをテーマにセッションを行った。佐藤氏は難易度の高い技術課題を解決する事業部支援やセキュリティレビュー、構成管理改善を担当している。

同社ではSaaSを利用してJiraやGitHubを提供している。だがそこには様々な課題があり、中でも重要なのが「情報に対するアクセス制御の管理」「ISIDが管理するID体系に含まれていないユーザーの管理」「休眠ユーザーの管理」「退職者の管理」といった課題である。

SaaS利用における課題の多くはシングルサインオンの導入によって解決できると考えられているが、「そうではない」と佐藤氏は指摘する。

電通グループでは昨年より本格的にOktaによるシングルサインオンの導入が始まっている。Oktaに登録されているユーザーは派遣社員を含む電通グループ社員のみで、顧客や一時的な業務委託契約業者は管理対象にはならない。

GitHubではGitHub Enterprise Cloudを購入すると、SAMLとSCIMが使えるようになる。GitHubからSCIMの利用には、OktaのAPIトークンを使うが、そのためには電通のシステム部門から管理者権限を付与してもらう必要がある。

「管理者権限を付与されると、電通グループ全体のあらゆるユーザーの情報やグループの読み書きができるようになる。そのような過大な権限を受領することは、万一情報漏洩事故が発生した際、被害を拡大してしまうので望ましくありません」（佐藤氏）

GitHub Enterpriseを購入したうえで、AWSのIaaS上で自前運用するというアプローチも考えられるが、「ライセンス料を試算すると年間一億円を超えてしまう。GitHub Enterpriseにそれだけの価値があるのか、経営者を説得することはできなかった」と佐藤氏は語る。

一方、JiraもAtlassian AccessというSaaSを購入すると、SAMLとSCIMが使えるようになる。しかし、「私たちが期待するものとはかなり動きが違っていた」佐藤氏は明かす。

認可アプリケーションが提供している機能

そこでISIDでは、独自の認可アプリケーションを実装することになったのである。認可アプリケーションは、「通常のWebアプリケーションにある機能が一通りそろっている」と佐藤氏は続ける。

ログイン画面、機能の一覧が分かるメニュー画面、OAuth用の画面では、権限を管理するためのグループ名を一覧した上で、その内容を編集できる。また権限の管理画面で設定した内容が反映されるGitHubのリポジトリ作成画面やJiraのプロジェクト作成画面も用意されている。

また、できる限り少ない学習コストで高効率に成果の出せるアプローチを取るため、クラウドのマネージドサービスをできる限り利用することにした。そこで重要になるのが、セキュリティ対策である。

認可アプリケーションが採用している技術

認可アプリケーションは「TypeScript」で開発。アプリケーションからインフラまで全てを単一のプログラミング言語でまかなうことで、学習コストの削減を狙ったのである。

また、TypeScriptは出力できる成果の質と量を安定させられる機能を有していることも採用の理由だ。

「TypeScriptコンパイラの静的解析は、近い将来に起こる実行時エラーに対処する際に発生する時間の浪費から私たちを守ってくれます。この恩恵を最大限に受けるために、コンパイラのstrictモードを常に有効化しています」（佐藤氏）

TypeScript ESLintでレビューの省力化を行い、IDEはVS Codeを採用している。「VS Codeを選んだのは、TypeScriptの豊かな型情報を使ったシンタックスハイライトと入力補完が非常に高速に動作するから」と佐藤氏。

Windows標準で使いやすいターミナルであること、またVS Codeには活発な拡張の開発コミュニティがあり、非常に多くの拡張が提供されている。それらを組み合わせて使うことで、生産性をより向上させることができるという。

例えば「Visual Studio Live Share」は、オンラインでワークスペースを共同編集できる拡張機能である。「コロナ禍で高度な共同作業を行う時に非常に役立った」と佐藤氏。そのほかにも、「REST Client」「GitLens」「.gitignore」「ESLint」「EditorConfigとPrettier」などの拡張をよく使っている。

アプリケーションインフラのセットアップには、「AWS CDK」を使っている。AWS CDKはTypeScriptやJava、Pythonといったプログラミング言語を使って、CloudFormationテンプレートを書ける技術。CDKのコード自体は普通のNodeプロセスなので、CLIアプリケーションとして実行できることはほぼできる。

「例えば、デプロイ済みのEIPをAWS SDKを使って取得したうえで、CloudFormationテンプレートにリテラルとして記述することが可能です」（佐藤氏）

AWSが提供しているサービスを活用

セキュリティ強化策の一環として、AWSが提供している「CloudFront」サービスを利用している。CDNサービスをアプリケーションの前段に配置し、SYN FloodのようなDDoS攻撃対策に活用している。

また認可アプリケーションのフロントエンドはAPI GatewayとAWS Lambda、バッチ処理は、ECS-Fargateを使って実行している。

「どちらも必要に応じてコンピュータ資源が起動する構造になっているので、原理的に本番環境にsshアクセスしない運用になっています」（佐藤氏）

そして秘密情報は、AWS Secrets Managerで管理。認可アプリケーションにおけるバッチ処理では、DistrolessをDockerコンテナのベースイメージにしている。DistrolessはGoogleの人たちがメンテナンスしているDebianベースのコンテナイメージだ。

「Distrolessの素晴らしい部分はシェルがインストールされておらず、アプリケーションのランタイムだけを動かすモデルであること」と佐藤氏は説明する。アプリケーションからOSコマンドインジェクションに類する脆弱性の影響を根本的に拭い去ることができるのだ。

Distroless最新版しかないため、ここに引っかかりを感じる人も多い。だが、最新バージョンしかないことで、細かいバージョン調整をする必要がないとも言える。

「Distrolessを使うには、ビルド用のコンテナと実行用のコンテナを分ける必要があること。これだけは覚えておいてほしい」（佐藤氏）

アプリケーション実装にはReactを選定

アプリケーションの実装にはReactを採用している。採用の理由は、アプリケーションを一定以上の期間メンテナンスしていく予定があるため。Reactには長期間のメンテナンスに耐えられるアプリケーションの実装方式「Stateless Functional Component」があるからだという。

第二にNext.jsを使うことで、SPAにおける最新のベストプラクティスに従ったデプロイが行えること。第三にUIコンポーネント集「Material-UI」を使うと、簡単に見た目にきれいな画面を実装できる。

最後に佐藤氏は、「セキュリティ対策においては唯一絶対の解はなく、その時々に応じて実現可能で妥当な対応を積み重ねるしかないと考えている」と語り、セッションを締めた。

続々と質問が寄せられた参加者とのQ&Aタイム

今回もセッション後に、参加者からの質問に答えるQ&Aタイムが設けられた。

Q.コンテナのセキュリティとしてできることは？また、コンテナのセキュリティはホストOSと比較してできることが限定されるか

佐藤：特に使用しているDistrolessにはシェルがないので、アプリケーションを動かすことしかできません。フロントエンドのアプリケーションを動かしているのはLambdaのため、何もできず、バッチの方もユーザとは何も繋がっていないので何もできません。

コンテナのセキュリティは、ホストOSと比較してもできることはかなり限定されています。使いやすいかどうかの回答でいえば、ホストOSは何でもできる。ただし、私たちは何もできないように制限しています。

Q.UIのテストとAPIのテストはどのように実施されているか

佐藤：UIのテストは、React Testing LibraryというDOMのAPIをJest経由で使っています。

Q.コンテナ開発において、イメージのセキュリティはどの程度対応できているか

佐藤：コンテナはDistrolessが機能する以上の対応はしていません。

Q.後継者の育成対策は？

富田：新卒入社者の場合は、まずシステム開発を学び、その上で、セキュリティの知識を学びます。最初は脆弱性検査を担当し、Webアプリケーションの構造や脆弱性の知識をつける。その後、設計レビューを行うという順番で育成しています。

佐藤：楽しいと思える方にはいろいろなことが教えられるので、「セキュリティ検査が楽しいと思えること」を重視して育成しています。

Q.ISIDのWeb開発案件での言語比率は？また、一番多く利用されている開発言語は何か

富田：一番多いのはJavaです。言語比率の6割を占めています。

佐藤：特にJavaが多いですね。Web開発をやっていない事業部は、.Netが多い。金融事業部でも、最近はJavaScriptが増えてきました。Goを使ってシステム開発している案件もあります。

ISIDにおけるセキュリティの仕事が紹介された今回のミートアップ。アプリケーション開発者の参加者が多く、セッション中も質問が飛びかうなど、非常に盛り上がりを見せた。次回のテーマも期待したい。