在DAM市場中，IBM InfoSphere Guardium可說是少數具備阻斷（Block）機制的解決方案之一，台灣IBM軟體事業處資深技術顧問張寅建不諱言，由於阻斷的原則是依據政策來執行，其中必須經過比對與判斷，因此連線至資料庫的封包勢必皆要經過解析，如此一來自然可能影響回應速度。
對此Guardium設計提供兩種不同的阻斷方式：主動式與非主動式。這兩種方式該如何取捨？張寅建建議，若資料庫系統提供服務的對象是線上應用程式，可採非主動式，因為效能更重要，不能因此影響到營運；資料庫服務的對象是企業內部人員，可能經由Telnet等方式直接遠端登入資料庫系統，這類非關鍵性任務存取行為，回應速度稍慢影響不大，就可採用主動式防禦。
Guardium得以在DAM中納入阻斷機制，跟其產品架構有關。市場上常見的DAM閘道器，多數架構是藉由交換器的Mirror Port來記錄，但Guardium是在資料庫系統安裝S-TAP（Software tap）於驅動層的方式來實現。
 |
| ▲台灣IBM軟體事業處資深技術顧問張寅建指出，確保資料庫安全首先要先了解資料庫本身可能存在的風險，之後定義敏感資料，並找到存放的位置，最後才是DAM的監看與防護。 |
「也曾遇到客戶詢問，在重要的資料庫系統上安裝任何程式都可能帶來風險，為什麼不採用Mirror Port？但是既然資料庫安全很重要，就要全面性考量，不該有所遺漏。」張寅建進一步說明，Mirror Port本身就會發生遺漏，因為交換器上頂多可配置兩個Mirror Port，常見一端接網路流量監控，另一端接DAM，當封包數量增多產生佇列（Queue）滿載與碰撞（Collision）導致Packet Loss時，Mirror缺乏確認機制，也就無法得知究竟封包是否有遺失。對於資料庫稽核監控而言，只要可能有遺漏就等於無效，不夠嚴謹。
「但是Guardium技術是直接在資料庫系統的驅動層運作，不管資料庫同時有多少連線存取，雖難免會增加運算負擔，但大約只有3%到5%，不致影響到整體運作，因此Guardium不需透過Mirror Port，只要透過S-TAP機制，就可以直接在資料庫系統上監看，不會有遺漏的風險。」張寅建強調。
Guardium的S-TAP機制不僅可監看結構化的資料庫，非結構化的資料處理也率先加入支援。在Hadoop Distributed File System環境，散落在四處的Data node，會有一個Name node來管理各檔案屬性與權限等資訊。不論此系統是採Hive或MapReduce程式框架，所有的行為都會經過Name node，而Guardium於新版9.0開始，已可直接在Name node上增加S-TAP，讓Hadoop所處理的資料也得以被監看與記錄。