システム開発・運用における内部不正は、重大な情報漏えいを引き起こし、企業に深刻な被害をもたらします。時には存続にかかわることもあるほどです。そのため、多くの企業が何らかの対策を実施・検討しているのではないでしょうか。
ただし、対策を施す対象は本番環境の個人情報に限定される傾向があります。その結果、内部統制や監査が本番環境に集中し、それ以外の環境は管理が疎かになりがちです。しかし、機密情報は本来それだけに限りません。
近年、退職者による技術情報の持ち出しや悪用、ソースコードの流出などが多発し、被害が増加しています。その際、プログラミング環境、テスト環境、ステージング環境など、本番環境以外の環境（以下、開発環境）にある情報が漏えいして起こるケースが多く見られます。もちろん、社内だけでなく、委託先でも起こることです。
本記事では、開発環境から情報漏えいした事件を整理した上で、開発環境における内部不正対策の必要性や課題、すぐに始められる３つの対策について解説します。
▶『サイバー攻撃・内部不正による情報漏えいを効果的に防ぐ手段とは？』を読む
開発環境から情報漏えいした事件
本番環境には多くの機密情報が格納されており、厳密な統制が必要ですが、開発環境も決して無視できません。開発環境が統制できていないと、企業の信用を失う大きな事件が起こる危険性があるからです。
本章では、実際に起きた事件を参考に、開発環境の統制がいかに重要なのかを確認します。
開発環境を使った内部不正
2021年、ある証券会社において、システムの開発・保守を担当していた委託先企業の元社員が顧客の口座から約2億円を不正出金した容疑で逮捕されました。犯行は約2年半にわたり、顧客の通報で発覚しました。不正の手口は次のとおりです。
図１：開発環境を使った内部不正の手口
- ① 委託元にある本番環境から、顧客情報を含んだバックアップファイルを作成
- ② ①を委託先にある開発環境に転送
- ③ ②から顧客情報を抜き出し、私用のメールアドレスへ転送
- ④ 盗んだ顧客情報（ID、パスワード）を利用して顧客の口座へアクセス
- ⑤ 顧客の口座から自身の銀行口座に送金
- ⑥ 多額の現金を引き出し
本番環境を含む様々な箇所でセキュリティ上の問題があったと考えられますが、注目したいのは、開発環境が利用された点です。開発環境への個人情報の格納を禁止する企業が多い一方で、そのルールが実際に遵守されているのかをチェックしている企業は少ないのではないでしょうか。
開発環境では、本番環境に比べて開発者の操作権限が多く与えられ、制約が少ない傾向があります。一方で、社内メール、ファイルサーバー、オンラインストレージなどに自由にアクセスできるケースが多く見られます。いったん開発環境に機密情報を格納されると、情報漏えいが発生するリスクが格段に高まると言えるでしょう。
さらに、開発環境では操作ログの取得やモニタリングが確実に行われていないケースが散見されます。その場合、情報漏えいの発見が遅れやすく、その間に被害が拡大してしまいます。
ソースコードの流出による被害
2022年、ある大手自動車メーカーが「委託先企業がソースコードを誤ってGitHubに公開した結果、メールアドレスとお客様番号が漏えいした可能性がある」と発表しました。ソースコードにデータサーバーへのアクセスキーが含まれていたのです。
このように、ソースコードにはアカウントのパスワード情報、SSHキー等の鍵情報、他サービスにアクセスするためのトークン情報など、機密情報の漏えいにつながるデータがハードコーディングされている場合があります。
ソースコードに含まれる脆弱性が悪用されるケースもあります。同年、パスワード管理ツールが攻撃を受けてソースコードが盗まれ、ユーザーのデータにアクセスされる事件が起こりました。このように、外部からの攻撃によってソースコードを盗まれる事件も近年多発しています。攻撃者にとって、それだけ魅力的なものだと言えるでしょう。
2021年には、大手銀行を含む複数企業が開発を委託していたシステムエンジニアが、私欲のため、ソースコードをGitHubに公開する事件がありました。この時、機密情報の漏えいはなかったと報道されましたが、ソースコードの流出によりシステムの弱点を突かれたり、技術を盗用されたりと、今後大きな被害を生む可能性は否定できません。
以上のように、ソースコードの流出は、顧客情報の漏えい、システムの脆弱性をついた攻撃、技術の盗用など、企業にとって大きな損失をもたらします。一方で、開発者が最も持ち出しやすいものの一つがソースコードです。ソースコードの管理はもちろん、開発環境の統制を十分に行うことが求められます。
開発環境における内部不正対策
これまで見てきたように、開発環境にも機密情報が漏えいするリスクが潜んでいます。本番環境の内部統制だけをしていれば安心とは言えないのです。では、どのような対策をしたら良いでしょうか。
はじめに、リスクに応じて、どこまで統制するのかを意識しなければなりません。例えば、開発環境において、本番環境と同レベルのアクセス申請・承認プロセスを必須とするのは、現実的ではありません。利便性が損なわれ、コストやリソースがかかり過ぎるため、対策が形骸化してしまう恐れがあるためです。
セキュリティと利便性を両立しながら、効果的で効率的な対策をとることが求められます。そこで、IPAの「組織における内部不正防止ガイドライン」でまとめられている5つの基本原則から、開発環境において必要な対策を見ていくことにしましょう。
- 原則１．犯行を難しくする（やりにくくする）
- 原則２．捕まるリスクを高める（やると見つかる）
- 原則３．犯行の見返りを減らす（割に合わない）
- 原則４．犯行の誘因を減らす（その気にさせない）
- 原則５．犯罪の弁明をさせない（言い訳させない）
原則１．犯行を難しくする（やりにくくする）
対策を強化することで、犯罪行為を難しくすることを指します。
開発環境へのアクセスが必要なメンバーは限られているはずです。まずは、そのメンバーを整理し、適切なアクセス制御を実施しましょう。メンバーが退職・交代した際は、すぐに前任者のIDを消去しアクセスできないようにします。特に退職者からの情報漏えいは非常に多いため、不要になったIDは即座に消去する必要があります。
また、オンラインストレージや外部記憶装置への接続を制限するなど、情報の持ち出しが容易にできないようにします。例えば、2023年、USBを利用して個人情報を持ち出し、900万件ものデータが漏えいする内部不正事件がありました。たとえ開発環境でも、外部に情報を持ち出す手段はできるだけ限定する必要があると言えます。
原則２．捕まるリスクを高める（やると見つかる）
管理や監視を強化することで、捕まるリスクを高めることを指します。
事件・事故が発生した際に、誰が・どこで・何をしたのか、すぐに分かるように操作の記録（操作ログ）を取得しましょう。記録されていても開発者であれば改ざんや消去できるケースがあるため、操作ログを保護することも重要です。
また、定期的なモニタリングも必要ですが、すべての操作ログを対象に行うのは現実的ではありません。機密情報の持ち出し操作を重点的に確認するなど、ポイントを絞って行います。
さらに、誰がその作業を行ったのか、明確にすることも欠かせません。例えば、共有のアカウントを使って作業してしまうと、万が一不正を発見しても、操作した人が分からない可能性があります。個人を特定できるようにした上で、操作記録をとり、モニタリングしましょう。
原則３．犯行の見返りを減らす（割に合わない）
標的を隠す・排除する、あるいは利益を得にくくすることで犯行を防ぐことを指します。
開発環境やソースコードには、機密情報を格納できないようにしましょう。顧客情報はもちろん、ハードコーディングされた機密情報も危険です。どうしても置く必要がある場合は、暗号化するなど、容易に見られないようにしましょう。開発ルールとして決めておくことを推奨します。
原則４．犯行の誘因を減らす（その気にさせない）
犯罪をする気持ちにさせないことで、犯行を抑止することを指します。
それには、職場の人間関係や待遇が大きな鍵を握ります。開発に携わるメンバーの間で欲求不満やストレスを溜め込まないよう、円滑なコミュニケーションを行い、適切な労働環境を用意しましょう。
原則５．犯罪の弁明をさせない（言い訳させない）
犯行者が自らの行為を正当化できないよう、理由を排除することを指します。
「聞いていない」「知らなかった」と言わせないため、開発時のルールを定め、周知しましょう。一度だけではなく、継続した教育が重要です。社内だけでなく委託先に対しても、同様のルールを確実に理解してもらうようにしましょう。
開発環境の統制が難しい理由
開発環境において、前章で述べた内部不正対策を行うことは大切ですが、すべての対策を確実に実践している企業は少ないのが現状です。その背景に、どのような課題があるのでしょうか。
本章では、開発環境の統制が難しい理由について整理します。
リソース不足
システム開発において、企業がまず統制対象として優先するのは本番環境です。開発環境の統制は、人的リソースはもちろん、コストや時間を割くのが難しく、どうしても後回しにされる傾向があります。
本番環境に注力せざるを得ず、開発環境の統制にまで手が回らないケースが非常に多いのが実態です。
メンテナンス負荷の増大
システム開発には、プログラミング、テスト、ステージングなど、用途に応じて様々な環境が必要です。さらに、複数の環境を構築した上で、必要に応じて再構築や頻繁なメンテナンスが行われます。
そのため、ツールを導入した場合、環境を構築するたびに設定変更、検証、あるいは再インストールする必要があり、本番環境と比べてメンテナンス負荷が高くなります。
また、開発環境は、本番環境と比べて関係者が多く、メンバーが頻繁に入れ替わります。委託先の変更もよくあることです。環境ごとにID管理をしていると、メンバーが入れ替わるたびにIDの棚卸を行う必要があり、運用負荷が非常にかかります。その結果、管理し切れなくなり、ルールが形骸化してしまうのです。
環境が委託先にあるため管理が困難
委託先に開発環境がある場合、多くは直接的に管理することが困難です。一方、第1章で紹介したように、委託先の担当者から情報が漏れる事件は後を絶ちません。自社で万全なセキュリティ対策をしていても、委託先企業での対策が不足していれば、意味がないのです。
たとえ委託先による情報漏えいであっても、委託元は業務に大きな影響を受けると同時に、社会的信用を失う可能性があります。顧客への賠償は委託元が行うことが多く、膨大な負荷がかかるため、企業活動そのものに甚大な影響を及ぼしかねません。
今すぐ始めたい３つの対策
前章のような課題を抱える中で、どのような対策を実施したら良いでしょうか。ここでは、今すぐに始めることをおすすめする３つの対策と実現方法について解説します。ぜひ参考にしてください。
なお、次の順番に行うのが理想ですが、4.1項の整理に時間がかかる場合は、4.2項の「操作ログの取得」から対応すると良いでしょう。
セキュリティ状況の可視化
はじめに、開発環境におけるリスクポイントと統制レベルの現状を確認しましょう。特にハードコーディングされた機密情報は見落しやすいので注意が必要です。次に、各リスクポイントのセキュリティ対策状況を確認しましょう。
委託先に開発環境がある場合も同様に確認が必要です。下図は、NRIセキュアの情報セキュリティ実態調査『NRI Secure Insight 2022』で、サプライチェーンの統制状況についてアンケートした結果をまとめたものです。これによると、委託先のセキュリティ対策状況を把握している企業の割合は48％、その中で改善を要求しているのはわずか23％程でした。
図２：委託先のセキュリティ対策状況の把握割合
委託先のセキュリティ対策状況が自社の基準を満たしていなければ、対応を要求する必要があります。要求ポイントも併せて整理しましょう。
リソースに限りがある中、チェックリストの新規作成は難しい場合があるかもしれません。IPAから内部不正チェックリストが公開されていますので、参考にしてみてはいかがでしょうか。
操作ログの取得
すぐにでも対応したいのが、操作ログの取得です。操作ログがあれば、万が一事件や事故が発生した際、原因や被害規模を確認するのに大変役立ちます。一方、操作ログを取っていないと、誰が・いつ・何をしたのかが分からず、最悪の場合、解決できないという事態につながりかねません。
事件や事故は、不正から時間が経つほど被害が大きくなってしまうため、できるだけ早く発見することが重要です。操作ログを定期的にモニタリングして早期発見につなげましょう。
ただし、すべての操作ログをモニタリングするのは現実的ではありません。リスクのある操作を整理し、その操作が実行された際に行うなど、重要なものに絞ってモニタリングすることをおすすめします。
また、操作ログを改ざんや消去から守るためには、個人にログの管理を任せるのではなく、ツールを利用した管理が欠かせません。
ただし、開発環境は数が多く、メンテナンスの頻度も高いため、各環境のシステムやクライアント端末にソフトウェアをインストールするエージェント型では運用負荷がかかり過ぎます。一箇所で集中管理できるゲートウェイ型のツールを選ぶことで、導入や運用の負荷を下げることができます。下図にゲートウェイ型とエージェント型の違いをまとめました。
図３：操作ログを取得するツールの種類と比較
操作ログを取得する際には、開発メンバーに監視している旨を周知してください。それが内部不正の抑止力につながります。
アクセスの制御
前述のとおり、開発環境は関係者が多く、入れ替わりも頻繁な上、機密情報が漏えいするリスクが潜んでいます。無関係なメンバー（特に異動者や退職者など）がアクセスできる状態は非常に危険です。
したがって、開発環境においても次のアクセス制御が欠かせません。
- 必要最低限のメンバーだけがアクセスできるようにする
- 不要になったIDは即座に利用できないようにする
- 共通IDの利用時でも、各操作の利用者を明確にする
これらの制御は、手作業では抜け漏れが発生しやすく、運用負荷が高くなるため、操作ログの取得と同様、ツールの導入がおすすめです。IDを一元的に管理するID管理ツールでも制御可能ですが、システムの再構築やユーザーの入れ替えが多い開発環境では、棚卸しや設定の負荷が少ないゲートウェイ型のツールを選ぶことを推奨します。
図４：アクセス制御を行うツールの種類と比較
セキュリティと利便性を両立させる方法
前章で述べた「操作ログの取得」と「アクセスの制御」を行うためにツールを別々で導入するのは、手間とコストがかかります。導入後の運用負荷も考慮が必要です。そこで、両方の機能を兼ね備えたツールを利用するのも一つの方法です。
NRIセキュアでは、操作ログの取得とアクセス制御が同時に可能な「Access Check Essential」を提供しています。15年以上の販売実績を誇る特権アクセス管理ツール「SecureCube Access Check」をベースにした製品です。
図５：Access Check Essentialを利用したアクセス制御と操作ログ取得のイメージ
Access Check Essentialは、ゲートウェイ型を採用しているため、クライアント端末や管理対象システムにエージェント（ソフトウェア）をインストールする必要がありません。端末ごとにエージェントの配布・導入・アップデートを行う必要がないため、管理者の運用負荷を抑えることが可能です。
さらに、設定項目を極力減らし、メンテナンス負荷を減らすなど、低予算ですぐに導入できる工夫をしています。こうしたツールを活用することで、コストが限られる中でも、セキュリティと利便性を両立させた対策を短期間で実現することができます。
おわりに
開発環境の統制は、本番環境に比べて後回しにされる傾向があります。一方、開発環境から機密情報が漏えいした事件や事故は多発しており、リスクは無視できません。
本記事で紹介した、「セキュリティ状況の可視化」「操作ログの取得」「アクセスの制御」は、リスクの低減に欠かすことのできない対策です。公開されているチェックリストやツールを活用することで、限られたリソースでも実施できる効果的な内部不正対策となります。
本記事が、開発環境の統制状況を見直し、改善するきっかけになれば幸いです。
