通過等保2.0分析系統脆弱性：安全區域邊界篇 & 安全計算環境篇
編輯：2022-02-25 16:08:18
安全區域邊界在近幾年變得越來越精細越來越模糊，因為攻擊的形式、病毒傳播的途徑層出不窮，我以攻擊者的角度去看，任何一個漏洞都可以成為勒索病毒傳播和利用的方式，我們要做到全面補丁壓力重重，通過邊界劃分，依靠不同的邊界安全防護，在發生問題的情況下將損失降到最低。
1、邊界防護
自從出現了統方的情況后，醫院對于終端準入的關注度日益增加，出現了非法接入醫院內網，獲取處方數據的情況，在我看過大部分醫院準入系統后，在數據盜取者面前這個準入做了和沒有做一樣，這真的是一個防君子不防小人的系統，而那些統方者肯定已經超出了君子的范疇；通過傳統的 IP/MAC 綁定很容易被繞過，缺乏對終端上特征的判斷，而我目前更推薦是桌管 + 準入相結合，但這也不能完全避免非法接入的情況，并且醫院設備種類眾多，如設備儀器、攝像頭、門禁等，我曾經寫過一篇醫院零信任網絡安全架構的文章，想象著能通過操作系統、網絡、安全結合大數據分析、 SDN 的方式去嚴格控制醫院的準入，可能想象是美好的，但是國內的產品還不能完全滿足這個要求，因為結合了多個廠家的領先技術。
我們理解準入的時候其實很多時候已經走入一個死胡同，我們缺乏了對移動設備接口、電腦接口、物聯網通信、 5G/4G 通信都有可能成為準入的缺口，通過這些技術可以將外部網絡中轉后接入到內網，這些其實在我們的環境中已有很多案例。考慮大型設備的質控問題，進口品牌廠商就會在設備上安裝移動網絡 SIM 卡設備，除了大型設備，還有進口品牌的存儲上我也發現了這個情況，所以我們要管的不僅僅是能看到的這張“有形網”，更是這張不太能看到的“無形網”。
傳統的網絡安全都設置了三個區域， T rust 、 U nTrust 和 DMZ ， 而在當今的網絡安全中，任何事物其實都不可能完全信任，我們不僅要防外敵，同時也要防內鬼，一臺中勒索病毒的內網終端可能比來自互聯網的 DD oS 攻擊更加可怕，這樣看來要針對每一臺終端都要有相應防火墻的進出保護，而且該防護墻也不限于傳統意義的包過濾訪問控制，還要有 IPS 、 WAF 、 防毒、行為管理等庫，同時要配合外部的安全大腦，聯動其他安全產品共同防御，想到這里我又想到了新冠病毒，可能不亞于防護生物病毒的復雜度。
醫院有很多移動醫療業務場景，醫生 PAD 查房，護理 PDA 掃碼發藥、庫房 PDA 掃碼入庫等情況，有線的準入限制就如此薄弱，無線的準入限制就更加脆弱，曾經我就聽說有醫院出現非法授權人員通過無線網絡進行統方的行為，這聽起來已經是一件沒什么技術含量的操作， PC 端的桌面管理很多時候在移動終端上都沒有考慮，其實 MDM 移動終端管理這項技術已經很早就有。
近幾年出現的“零信任”模型，無非就是在傳統網絡準入上更近一步，結合傳輸層、應用層的判斷，對準入控制更加細化，原先一個終端對于網絡接入只有“是”或者“否”，而零信任的環境下就算終端接入網絡，終端上的程序是否能運行還要經過判斷，程序走的網絡流量要經過層層過濾和安全防護，就和疫情防控一般，從外地過來的，首先判斷是不是中高風險地區，如果是中高風險直接勸返或者隔離（準入控制），如果是低風險地區，依然隔離多日通過多次核酸確認后才能入境（沙箱），境內我們限制了部分場所的使用，如限制了電影院、 KTV 、 棋牌室等風險場所，限制了入境人員可能去的風險區域（桌面管理），通過各場所的健康碼掃碼記錄形成（日志審計），時刻要佩戴口罩進入公共場所（防火墻），最后該人員依然出現了疫情癥狀，傳播的范圍也可以控制到最小，并且通過掃碼行程和其他運營商信號關聯出其時空伴隨者（態勢感知），并一同隔離（殺毒軟件）。
2 、 訪問控制
在我原來工作的行業中，這塊的內容其實是一項基本要求，每天有大量的工作是對防火墻上添加訪問控制策略，要對工單表格中的內容進行合并同列項、歸類，還要在訪問沿途的防火墻上開通對應的策略，工作繁雜，對技術的要求其實不高，可能會遇到一些小問題，也就是長鏈接、 FTP 這些開放時要注意的問題。但是到了醫療行業，我咨詢了好幾家醫院，基本都沒有做訪問控制的，我分析了一下有幾個原因：
①考慮性能問題，其實這已經不是問題，云數據中心、 IDC 等出口都有包過濾防火墻設備，并且內部還有租戶單獨的防火墻設備，原單位的迪普防火墻號稱并發可以達到 8000 萬，當我用容器環境做并發鏈接測試的時候打到過 500 萬，防火墻的 CPU 、 內存沒有一絲波動，而基本上沒有醫院的數據中心鏈接并發能達到 500 萬的，而當時 J uniper 的 ISG 設備最高只能達到 2 萬的連接數，幾千的并發，所以設備合不合適要看設備的性能指標和新老，而這些都和投入的成本有關，這些都要嚴格要求集成商，不能配置低配的設備，造成后續業務升級過程中不必要的麻煩；
②缺乏規劃性，因為 IP 地址的規劃和終端 IP 功能的規劃，可能在開通防火墻的時候就要開通一個大段，這樣的做法不太符合最小化原則，這時候其實先要考慮前期 I P 的規劃，不同的 IP 網段有不同的功能，然后在開通防火墻的時候可以盡可能的按照最小化原則，而不至于有太大的工作量；
③服務資產不清，不清楚數據中心服務開放端口的資產情況，大部分服務器端的軟件都由軟件廠家管理，并且開放端口醫院信息科的人不清楚，連乙方部署的人都不一定清楚，很難在這樣一個基礎下建立起防火墻開放的流程；
④高可用性的擔心，在傳統的防火墻設計中，一般就考慮將防火墻串聯到網絡當中，實際在部署的時候有很多種方式，當時對于醫院這樣的環境，我們盡可能考慮最小影響，我推薦透明串聯 + 旁路 bypass 功能、策略路由旁掛 +SLA 檢測、 vxlan 安全服務鏈引流，其中都要確保單臺防火墻滿足網絡中最大流量，并且能夠在出現故障時實現主主切換、主備切換、故障旁路，將業務的影響降到最低，并且盡量確保那些長鏈接會話不受影響。
在醫院防火墻部署的位置上，我們要考慮信任和非信任兩個方面，首先相對于內部網絡，對互聯網和專網我們應該列入非信任（專網包括醫保、衛生專網等一切非醫院自己內部的網絡），相對于醫院內網，醫院的外網也是非信任區，相對于數據中心網絡，醫院的門診、住院等辦公網段也是非信任區，在這幾處我們都應該確保有防火墻防護，對應策略默認拒絕，按需開通服務。可能大家覺得部署這么多防火墻并沒有感受到很大的用處，大家在想想勒索病毒通過什么方式傳播，見的最多的是 SMB 服務，其實只要是漏洞在我看來都有可能被勒索病毒利用，如果在全網終端沒有打上補丁的情況下，我們除非有自動化工具能夠批量對終端進行防火墻下發，那在便捷性和實用性折中的情況下，我們還是會考慮使用網絡防火墻對勒索病毒傳播端口進行封堵，如果單位本來就建立了良好的按需開通訪問機制，在這個時候也就不會有很多擔憂。
3 、 入侵防范
a）應在關鍵網絡節點處檢測、防止或限制從外部發起的網絡攻擊行為；
b）應在關鍵網絡節點處檢測防止或限制從內部發起的網絡攻擊行為；
c）應采取技術措施對網絡行為進行分析，實現對網絡攻擊特別是新型網絡攻擊行為的分析；
d）當檢測到攻擊行為時。記錄攻擊源IP、攻擊類型、攻擊目標、攻擊時間，在發生嚴重入侵事件時應提供報警。
這里提到了外到內的網絡攻擊和內到外的網絡攻擊，外到內的防護毋庸置疑，而內到外的防護其實也是我們要考慮的，在網絡安全法頒布起，攻擊我國境內的網絡資產都會受到法律的制裁，為了保護自己單位不受影響，那對內到外攻擊的防護自然而然要被納入管理的范圍，像 C&C 攻擊、 DD o S 攻擊的肉雞，像對勒索病毒外聯的防護都是我們要考慮的，在保護他人的同時保護了自己。
對新型網絡攻擊行為的分析，其實早在 2014 年我就了解到了當時的 APT 產品（ 高級可持續威脅攻擊 ），深思現在的網絡架構，如果要發現新型的攻擊行為，那我們就要排除掉一切以攻擊庫、病毒庫為基礎的設備，包括傳統的防火墻、殺毒軟件等，在此基礎上，要聯動下一代墻、態勢感知、 EDR 等新型安全產品，甚至還要聯動產品公司外部的實時信息，關聯全球的安全情報，通過這樣的要求，我對這套體系的考慮是盡可能通過同一家公司的產品實現，可以想象一個中國人對一個不會說中國話的外國人說漢語的時候是什么樣的結果，就算雙方都是中國人，不同的方言理解起來其實也有困難（就好像不同的產品線在傳輸日志和分析日志的時候都有不同的方法），所以對新型網絡攻擊行為的分析，其實任重而道遠。
對于安全日志的收集、記錄、分析、告警對整個安全運營中心平臺也有很大的壓力，打個比方，在同一原地址對醫院多個互聯網地址進行攻擊時，原始的日志可能是成千上萬條的，如果這成千上萬條的日志不經過分析，直接告警，可能告警的短信平臺、微信平臺都會搞垮，安全日志分析匯聚的工作就尤為重要，不僅要對同一攻擊源的不同攻擊進行匯總，還要對不同攻擊源的同種攻擊進行匯總，甚至還要關聯前后攻擊的線索進行溯源。
說到審計看似很簡單，只要把日志傳遞到日志審計服務器記錄，可以通過各式各樣的參數查詢即可，但是日志記錄全不全、有沒有遺漏，我之前就碰到過好幾次溯源到一半失敗的情況，一次是訪問過程中有 NAT 設備，這個時間點 NAT 的日志沒有，沒辦法把前后的日志關聯起來，一次是設備上的攻擊源地址是白名單地址，而白名單地址攻擊不記錄在日志中，還有很多次因為終端上的日志沒有開啟，導致最后一步溯源失敗。
如果要將所有資產的日志進行審計記錄，并且記錄到位，還要做備份，其實這個量遠遠已經超過了 HIS 數據庫的增長量，而且網絡安全法的要求是日志記錄 180 天，我看了下我們光數據庫審計的日志每天就有 20 多 GB ，180 天將近 4TB 的容量，我們還有網絡設備日志、安全日志、操作系統日志、存儲日志、應用日志等等，加起來每天的量可能就達到上百 GB ， 如此大量的細小碎片化數據，要做到日志查詢不僅僅是一臺日志審計服務器能做到，我在購買數據庫審計的時候就測試了多家廠家的產品，不是日志遺漏保存，就是日志查詢速度慢，或者是日志查詢功能不全，如果是有能力的醫院，其實建議還是單獨自建開源的日志平臺，對日志流量進行清洗、匯總，通過相匹配的 NoSQL 數據庫記錄，簡單方便的可以考慮下 Elastic Search ，在查詢速度快的情況下，可視化也做的較好。
個人認為計算環境下的安全問題其實是最嚴重的，大部分中高危漏洞都從計算環境下發現，被利用最多的也是，而且計算環境的網絡資產量也是最多的，各種虛擬化、容器化、 S erverless 等技術將計算資源分成更小的細塊，提高了安全管理員的能力要求，更是提高了像 CWPP 、 EDR 等安全軟件的防護要求，在 “安全計算環境中”有些前面提到的內容就不再贅述。
在醫院中除了數據中心的服務器資源，還有醫護人員、行政人員使用的電腦都需要納入安全計算環境的管轄范圍。大家可以看看自己用的電腦是否設置了密碼，并且密碼的要求是否符合強口令（長度大于 8 位，包含大小寫字母、數字、符號，并且不包含鍵盤上連續字符或者英文單詞），并且 3 個月更換一次密碼。在 AAA 認證體系（ AAA 是認證（ Authentication ）、授權（ Authorization ）和計費（ Accounting ） ）中，第一關就是認證，在認證的過程中可能會出現如無認證、弱口令、認證可以被繞過、明文密碼傳輸等等問題，
不僅僅是在醫療行業，基本所有行業的內網環境都包含了上述問題，在護網行動中，打入了內網環境后，大量使用重復的弱口令，成為被攻陷的重要問題之一，有很多護網的案例是拿下了堡壘機的弱口令，而堡壘機上直接記錄了各類服務器的高權限賬號密碼，通過一點突破全網。我們大家可以看看自己的環境下， PC 和服務器端是否存在無認證、弱口令的情況，除了 RDP 、 SSH 等常見管理服務，還有 Radmin 、 VNC 、 SMB 、 FTP 、 TELNET 、 Oracle 、 MySQL 、 SqlServer ， 根據我一直以來的工作經驗，很多開源軟件的早期版本對于 API 接口就根本沒有認證機制，所以還有很多的開源服務如 Redis 、 Docker 、 Elastic Search 等，有認證的情況下是否使用了開源軟件的默認賬戶口令，這個也需要我們及時修改，黑客可以通過一點突破，層層收集信息，最終突破核心防線。
AAA 體系中的第二步授權，其實是可以緩解第一步問題的一個手段，理論上要求我們的 PC 端、服務器端不同的軟件需要通過不同的用戶安裝、使用，并且不同的用戶只能給予最小安裝、使用軟件的權限，而我們可以檢查下自己的環境，應該是有很多直接使用 administrator 、 root 等用戶，并且這些賬號存在著復用的情況，在使用過程中很難分清楚現實生活中的哪個自然人使用了這個賬戶進行了相關操作，如果出現了問題給后續溯源提升了難度，我們這時就需要通過 IP 、 上層的堡壘機日志等進行關聯溯源。
限制登錄失敗次數是防止暴力破解的手段之一，暴力破解會通過一個密碼本對需要爆破的服務密碼進行不斷的嘗試，直到試到正確的那個密碼或者密碼本試完為止，正常人登錄一般都會記得自己的密碼，當然在定期更換復雜密碼的要求下，正常人也會記不住密碼，這個問題我們后面再說。在限制了登錄失敗次數，比如我們設置了 5 次，那通過某個 IP 登錄失敗 5 次后這個 IP 就會被鎖定，當然可以設置別的 IP 還可以登錄這個服務。會話結束功能就類似于 W indows 自動鎖屏，作為一個信息工作者，在我們離開電腦時就應該考慮鎖屏的操作，并且重新登錄要輸入賬號密碼，一個不會超時的會話雖然方便了我們自己，同樣也給惡意者帶來了方便，想想經過你辦公桌的每個人都可以在登錄著的 HIS 服務器或者核心交換機上敲一個 reboot ，最后造成的結果可想而知，雖然這個事故不是你直接操作的，但也要負主要責任。
在醫院中常見的遠程管理手段有 RDP 、 SSH 、 TELNET 、 FTP 、 Oracle 等，其中 TELNET 、 FTP 在流量劫持時可以直接獲得賬戶口令信息，可以通過 SSH 、 SFTP 等方法替換，確保在賬號密碼認證和數據流傳輸過程中都是加密的。其實 Oracle 的流量也非加密，在我咨詢了我 OCM 的朋友和百度后，發現其實 Oracle 流量也可以配置加密，但是我們很少會這樣做，并且很少會有人關心這個問題，還消耗客戶端和服務端額外的性能。這時候我們就要想到什么時候我們的流量會被截取走，常見的就是內網 ARP 欺騙，一臺攻擊主機在客戶端請求網關 MAC 地址的時候，將自己的 MAC 地址告訴客戶端，說自己這個 MAC 地址就是網關的 MAC ， 這樣二層的流量會先通過這臺攻擊主機轉發給真實的網關，所有明文的流量過了這臺攻擊主機后就可以被它輕松的獲取敏感信息，我的防護方法是通過桌管軟件，將每個網段主機的網關 ARP 解析靜態的寫到客戶端上，確保 ARP 解析時默認都先通過本地記錄解析，從而不會被外部動態解析影響。另一種情況會被獲取的是網內的流量設備，很多安全設備、 APM 監控設備、深度流量分析設備都需要抓取核心網絡的流量，當這些流量被鏡像給設備后它們會將它記錄下來，而正式或者測試設備出現問題返廠時，我們就要叮囑工程師要清空本地數據，以免數據泄露，在我的工作中就聽到過通過安全設備泄露大量公民信息的案例。
前面我們說到要定期修改復雜密碼，但是經常修改會導致管理員記憶困難，這個時候我覺得雙因子認證也是幫助大家不用記復雜密碼的好方法。雙因素認證分為所知和所有兩種，雙因素的證據又分為秘密信息、個人物品、生理特征三種類型，像口令、密碼就是信息，物理 key 就是個人物品，指紋、虹膜、面部就是生理特征，我們只要結合兩種類型的證據，那就符合要求，可以通過物理 KEY+ 動態密碼的方式實現認證，此時就不用記住原始的靜態密碼，大家可以想象一下現在在登錄微信、支付寶、 QQ 等互聯網軟件的時候基本很少使用密碼，而智能手機也將密碼和人臉識別關聯，方便大家認證操作，同時又符合安全要求。在醫院工作的過程中，我發現很多業務系統的賬號密碼不是同一套體系，系統在認證時也沒有做到雙因子的要求，我之前寫過一篇論文，叫《基于 4A 系統的醫院零信任網絡安全模型》，也是我希望能通過安全技術提升醫護行政人員使用系統時的便利性、規范對醫院所有系統賬戶體系管理、加強醫院業務系統使用時的權限管理能力。
五級電子病歷評審中提到了系統備份、容災的標準，對醫院信息系統的穩定性、可靠性、可用性有了明確的要求，醫院信息系統的宕機、數據丟失會造成無法挽回的影響；2021 年《數據安全法》和《個人信息保護法》出臺，我國在信息化高速發展的當下，更加重視了網絡安全，證明了網絡安全與信息化是一體之兩翼、驅動之雙輪。
2 、數據保密性
信息安全 CIA 三要素，保密性、完整性、可用性，這里提到了數據的保密性，其實不管在哪個行業，數據的保密性都很難做，我們可以看到大量的公民數據在互聯網安全事件中泄露，我國之前的《網絡安全法》對數據安全沒有具體的要求，而 2021 年的《數據安全法》和《個人信息保護法》才對數據安全有了明確的要求，并且這兩部法律給企業帶來了不小改造的壓力。
數據安全的保密性要求貫穿了數據的產生、傳輸、處理、存儲、銷毀等過程，首先我們要對數據進行保密，就要知道哪些數據應該保密，此時要做的就是數據的分類分級，在分級分類過程中涉及到對敏感數據的發現，敏感數據除了結構化的還有非結構化的，除了關系型的還有非關系型的，基本很難做到全覆蓋，比如在護網期間就發現有很多日志、配置文件中帶著敏感的賬號密碼等信息，而這些信息的配置可能是套裝化軟件不能修改的。在發現了敏感數據后我們就要對敏感數據進行加密、脫敏、去標識化操作，在五級電子病歷的要求中也有一條數據加密的要求，數據加密其實有兩種做法，一種是在存儲層（通過存儲設備進行加密），另一種在系統層（通過對操作系統的配置文件，或者對數據庫的數據進行加密），第一種方法的難度較小，而第二種方法的難度較大，需要考慮數據被加密的方法和被使用過程中的解密，對于數據量小可以考慮非對稱加密，而數據量大的只能使用對稱加密，這也就是 SSL 的機制，通過非對稱加密秘鑰，然后通過秘鑰對稱加密數據流，在確保業務正常的情況下，實現安全的需求。針對脫敏、去標識化操作可以通過好幾處實現，可以通過后端實現，也可以通過前端實現，通過后端實現時當數據從應用層往前端傳輸時就是去脫敏、去標識化的數據，甚至是在數據庫中就是脫敏、去標識化的，而在前端實現，我們可以在客戶端本地開啟代理，直接可以獲得明文的數據，從安全性來考慮肯定是后端實現更安全。
我們在做數據加密、脫敏、去標識化時要考慮的重要一點就是業務是否支持，有些數據雖然是敏感數據，但是以密文呈現時是無法進行正常業務的辦理和交互的，如果要實現正常業務辦理和交互，可能需要改變流程、規范，并且付出巨大的代價，在醫院以業務為中心的情況下，個人覺得短期內很難很難實現，我個人在落地一個數據安全的產品時就提出了這樣一個問題，該產品邏輯串聯在數據庫客戶端和數據庫服務器之間實現數據庫字段的加密、脫敏、去標識化操作，而我們的 HIS 業務每天都有大量的問題要處理，在處理過程中需要通過這些敏感的數據進行確認、判斷、修改，不可能專門安排一個人每天在對字段做解密、加密的操作，還需要配合專門的流程來規范這個操作，在一個業務系統沒有穩定、技術人員缺乏的情況下，這樣的功能很難落地，就算落地了也只是很小的范圍，如何滿足二者需要靠廣大讀者來幫忙想想辦法了。
3 、 數據備份恢復
我問了很多醫院，大家可能都建立了容災環境，但是很少有醫院做容災測試，對于五級電子病歷的要求是每年至少一次的容災演練（還需要結合業務場景），每季度至少一次的數據全量恢復測試，一個沒有測試過的容災系統真的很難讓人相信在出問題的時候可以撐得住真實業務，也許容災的切換過程沒有問題，但是容災的硬件資源、硬件配置、軟件調整等是否能讓用戶在較短的時間內進行邊便捷的切換操，五級電子病歷對于數據丟失的要求比較松， 2 小時以內即可，但是醫院對于數據丟失是難以容忍的，對于信息化較長時間都無法正常使用也是無法容忍的，我們要盡可能做到 RPO 、 RTO 最小化。
對于備份，我盡量做到 321 原則， 3 份數據、 2 種不同介質、 1 份存于異地，結合第一點和第二點，我將數據存放于起碼 2 種不同物理設備上，存儲 3 份，再結合第三點將一份數據存儲于異地，兩份數據存于本地。我們醫院有兩個院區，兩院區直線公里數其實小于 40 ㎞ ， 而等保的異地要求是直線大于 100 ㎞ ， 對于沒有分院的小伙伴們，其實我建議可以將另一份數據存到異地云上，最起碼在本地真的數據沒辦法恢復時還有一根救命稻草，雖然恢復的時間可能會長一點。我會將兩院區的數據做相互的異地備份，盡可能提高數據備份的頻率，減少數據的丟失，核心業務系統采用實時備份或者容災的方式，在使用較高頻率備份的情況下，我們對于備份、容災的硬件就有一定的要求，較差的 HDD 盤是無法支撐起大數據量、高并發的備份任務，可能出現任務排隊，那就會得不償失；在備份上我們就出現過一個問題，之前工程師在配置 RMAN 備份保留的腳本操作是先刪除原來的備份，在進行下一次備份，如果前一次備份刪除了，后一次備份沒有成功，那就沒有了全量數據，這樣的備份是沒有意義的，大家可以檢查下自己的環境是否存在這樣的問題。
在備份的類型上，分為物理備份和邏輯備份， 21 年我就聽到了別的醫院出現了 Oracle 的邏輯壞塊，出現壞塊后數據庫無法正常啟動，而容災系統通過 Oracle Data Guard 實現， DG 屬于物理塊同步，面對邏輯錯誤不會校驗，而直接將這個邏輯錯誤同步給了容災庫，導致容災庫也無法正常拉起，并且當時也沒有配置長時間的閃回空間，導致最后花了很大的代價才恢復了一部分丟失的數據，并且業務中斷了很久，可以通過 OGG 解決這個問題，并且 OGG 可以支持跨數據庫、操作系統類型之間的數據復制，但是配置難度比 DG 大了很多；另外的辦法是通過 CDP 實現 IO 級別的備份，當出現邏輯錯誤數據庫無法正常使用的時候，通過 CDP 的 IO 回退到正常的時間點，當然中間丟失的數據需要人工去彌補，這樣通過數據庫外部的方式解決數據備份的問題。
4、個人信息保護
這兩點在《個人信息保護法》中也有明確提到，該法律中多次提到了收集個人信息要有“詢問 - 確認”的過程，并且在用戶不同意提供個人信息的情況下，不能拒絕對用戶提供服務，只收集必需的個人信息，要告知用戶收集每種類型個人信息的目的，告知用戶如何處理、傳遞、使用個人信息。在疫情當下，全國的醫院都緊鑼密鼓的推廣互聯網醫院，意味著有一個面向患者的醫院互聯網系統，患者可以直接面向這個互聯網系統，那對系統的提交信息、問詢交互有了更直接的了解，我們在做互聯網系統的時候要結合《網絡安全法》、《數據安全法》和《個人信息保護法》三駕馬車來嚴格要求開發時的安全需求，自從三部法律上臺后有多少互聯網 APP 因不符合要求被責令整改、罰款、下架等，我們也該引以為戒。
文章來源：天億網絡安全
咨詢熱線：0351-4073466?
地址：（北區）山西省太原市迎澤區新建南路文源巷24號文源公務中心5層
? ? ? ? ? ?（南區）太原市小店區南中環街529 號清控創新基地A座4層
