1月28日 SMBCのシステムに関するソースコードの一部が、「GitHub」という外部のWEBサイト上で公開されていた事が判明しました。
その後SMBCは1月29日に自社サイト内で
「公開されたソースコードは、当行のセキュリティ環境全体に影響を及ぼすものではございません。」
と明記していますが、ソースコードの漏洩の経緯についてネット上で話題になっています。
本人に情報漏えいの自覚が全くなかった?
今回の情報漏洩事件について、まず情報を公開した方はSMBCの委託先企業のシステムエンジニアで、「GitHub」に情報をアップロードした理由について、
「転職を希望しており「GitHub」上にアップしたソースコードから年収を診断できるサービスを利用するために、手元にあるソースコードを全てアップロードしました。」
ソースコードを「GitHub」にアップロードすることについては、契約書や覚書を交わした記憶はあったが問題になるとの認識はなかったようです。
また「GitHub」にアップロードした内容が公開されている事についても、デフォルトの設定で公開になっていることを知らず公開されている認識はなかったとしています。
以上のことから、これが情報漏洩にあたるという自覚が全くなかったと考えられます。
情報漏えいのリスクを減らすにはどうしたらよい?
再発防止のためにはツール類を禁止にするだけでは効果がなく、情報漏洩に対する正しい知識を教育する必要があると思います。
今回のような認識不足による情報漏洩のリスクは、クラウド上で提供されるサービスでは常に可能性があるようです。
例えば翻訳サービスなども翻訳結果が残るものであった場合、その内容が機密情報にあたるものであれば情報漏洩になるケースもあります。
この場合も利用者は「翻訳をしたかった」だけで情報漏洩の認識はないでしょう。
このような認識不足による情報漏洩リスクは、自社でも起こりうる新たなリスクとして認識する必要があります。
機密文書に関しても「シュレッダーにかけるのが面倒」なので、機密文書をそのままゴミ箱に丸めて廃棄してしまい情報漏洩するケースが跡を絶ちません。
「そんな事するわけないだろう」と思う人が多いかもしれませんが、今回の事件のように認識不足から「これくらいはいいだろ」とやってしまう人も大勢いらっしゃいます。
そういった人を社内で認識することは難しく管理も大変です。
(シュレッダーのメリット・デメリットの詳細は「機密文書の廃棄方法|シュレッダー処理のメリットとデメリット」を参照)
そんな場合は、
そもそもの「シュレッダーにかけるのが面倒」を解消することでリスクを抑えることが出来ます。
弊社ではその為に「機密文書の溶解処理」を推奨しております。
ご興味のある方はご案内できますので是非一度ご相談下さい。