一起客戶生產環境中所有NAS資料被盜的事件

前言

數年前我參與了一個系統開發，而在那段時間發生了一件將客戶端NAS數據全部rm的事件。

這個系統由多個子系統和NAS組成。
我負責其中一個子系統的開發，這次事件是在進行不具合修正的更新時發生的。

事件起因

這一天，我們照例進行不具合修正的更新，但我因為忙碌無法前往現場。因此，我請別的子系統的開發人員A君順便幫我進行更新作業。更新作業本身只需停止應用程式，並執行更新用的shellscript，工作相對簡單。

當天晚上，現場的課長打來電話。
「A君正在進行更新，但現在現場發生了NAS數據全部消失的事件。我們正在忙著作業，這應該跟我們無關吧？」
我完全沒有頭緒，但仍決定稍微調查一下。

調查shellscript

這個子系統的目錄結構如下：

root/
├app/
│└ EXE
├lib/
│└ LIB
└data/
　 └ MOUNT

查看更新用的shellscript，其內容顯示：

rm -rf /app
rm -rf /lib
rm -rf /data

這一行表明為了替換應用程式而刪除了所有文件。
我確信罪魁禍首就是我。

過去我進行過多次更新，但這次為什麼會發生呢？

為何會發生此次事件

事件發生的經過如下：

進行Bug重現實驗
由於Bug導致應用程式崩潰
實施更新

在應用程式停止時，必須解除掛載。
但由於Bug導致應用程式崩潰，因此解除掛載的處理並未執行。
因此，根據上述的shellscript，導致整個掛載目錄，也就是NAS被刪除了。

事件發生的原因有以下三個：

完全不懂子系統的人進行作業

直接引發事件的A君是負責別的子系統的，對這個子系統完全沒有接觸過。因此，他對於掛載位置等並不知情。
如果是懂得子系統的人，或許能夠察覺掛載尚未解除的情況。

系統設計不當

僅僅執行rm而不解除掛載，似乎只會刪除自己子系統的NAS數據區域。
但是這個子系統是掛載於NAS的root上。
本系統需要使用另一個子系統的數據，但在未創建共用空間的情況下，卻犯下了將NAS的root掛載的愚蠢行為。
因此，才導致能夠把NAS數據連根全部rm掉。
（由於系統的特性，權限完全授予也產生了協同效應。）

完全不知道更新用shellscript的內容

作為系統的負責人，在這次事件發生之前，我從未查看過shellscript的內容。這意味著我一直在使用一個不知道其具體執行內容的shellscript來進行應用程式的正式環境更新。
由於開發體制相當糟糕，我無法全盤顧及，導致許多源碼都未曾查看過。即便如此，仍需要進行發布，所以經過測試的一些東西才得以釋出。這個shellscript也是外包商為測試環境製作的，而我卻沒有更新任何東西地直接重用。