A. 資料庫安全的概念是什麼一般影響資料庫安全的因素有哪些
資料庫安全包含兩層含義：第一層是指系統運行安全，系統運行安全通常受到的威脅如下，一些網路不法分子通過網路，區域網等途徑通過入侵電腦使系統無法正常啟動，或超負荷讓機子運行大量演算法，並關閉cpu風扇，使cpu過熱燒壞等破壞性活動； 第二層是指系統信息安全，系統安全通常受到的威脅如下，黑客對資料庫入侵，並盜取想要的資料。資料庫系統的安全特性主要是針對數據而言的，包括數據獨立性、數據安全性、數據完整性、並發控制、故障恢復等幾個方面。
資料庫安全的防護技術有：資料庫加密（核心數據存儲加密）、資料庫防火牆（防漏洞、防攻擊）、數據脫敏（敏感數據匿名化）等。（來自網路）
安華金和針對於資料庫安全的防護技術全部擁護，並且在政府、金融、社保、能源、軍工、運營商、教育、醫療、企業等各行業樹立多個標桿案例。
B. 資料庫系統的安全措施有哪些
資料庫數據加密
數據加密可以有效防止資料庫信息失密性的有效手段。通常加密的方法有替換、置換、混合加密等。雖然通過密鑰的保護是資料庫加密技術的重要手段，但如果採用同種的密鑰來管理所有數據的話，對於一些不法用戶可以採用暴力破解的方法進行攻擊。
但通過不同版本的密鑰對不同的數據信息進行加密處理的話，可以大大提高資料庫數據的安全強度。這種方式主要的表現形式是在解密時必須對應匹配的密鑰版本，加密時就盡量的挑選最新技術的版本。強制存取控制
為了保證資料庫系統的安全性，通常採取的是強制存取檢測方式，它是保證資料庫系統安全的重要的一環。強制存取控制是通過對每一個數據進行嚴格的分配不同的密級，例如政府，信息部門。在強制存取控制中，DBMS所管理的全部實體被分為主體和客體兩大類。主體是系統中的活動實體，它不僅包括DBMS 被管理的實際用戶，也包括代表用戶的各進程。
客體是系統中的被動實體，是受主體操縱的，包括文件、基表、索引、視圖等等。對於主體和客體，DBMS 為它們每個實例(值)指派一個敏感度標記。主客體各自被賦予相應的安全級，主體的安全級反映主體的可信度，而客體的安全級反映客體所含信息的敏感程度。對於病毒和惡意軟體的攻擊可以通過強制存取控制策略進行防範。但強制存取控制並不能從根本上避免攻擊的問題，但可以有從較高安全性級別程序向較低安全性級別程序進行信息傳遞。審計日誌
審計是將用戶操作資料庫的所有記錄存儲在審計日誌(Audit Log)中，它對將來出現問題時可以方便調查和分析有重要的作用。對於系統出現問題，可以很快得找出非法存取數據的時間、內容以及相關的人。從軟體工程的角度上看，目前通過存取控制、數據加密的方式對數據進行保護是不夠的。因此，作為重要的補充手段，審計方式是安全的資料庫系統不可缺少的一部分，也是資料庫系統的最後一道重要的安全防線。
C. 在雲平台上的資料庫主要面臨哪些安全問題
資料庫存儲著系統的核心數據，其安全方面的問題在傳統環境中已經很突出，成為數據泄漏的重要根源。而在雲端，資料庫所面臨的威脅被進一步的放大。其安全問題主要來自於以下幾方面： 1） 雲運營商的「上帝之手」。如上所述，雲端資料庫的租戶對資料庫的可控性是很低的，而雲運營商卻具有對資料庫的所有許可權。從技術上來說，雲運營商完全可以在租戶毫無察覺的情況下進入資料庫系統；或者進入資料庫伺服器所在的虛擬機；或者進入虛擬機所在的宿主物理伺服器；或者直接獲取到資料庫文件所在的存儲設備。也就是說，任何租戶的數據，對雲運營商來說，幾乎是完全開放的。而對於有商業價值的數據，對雲運營商的眾多技術人員來說，絕對有足夠的吸引力；2） 來自於其它租戶的攻擊。同一個雲平台上的其它租戶，有可能通過虛擬機逃逸等攻擊方法，得到資料庫中的數據；3） 來自租戶自身內部人員的威脅。租戶內部人員能夠直接使用帳號密碼登錄到雲資料庫，從而進行越權或者違規的數據操作；4） 更廣泛的攻擊。有價值的數據放在雲上之後，各種來源的攻擊者，都「惦記」著這些數據。可能通過各種方法來進行攻擊以獲取數據，如近年來頻發的sql注入攻擊事件，就導致了大量雲端數據的泄漏。要解決如上所述的數據安全問題，需要多方面的防禦手段。但是對資料庫訪問情況的記錄和審計，是最基本的安全需求。租戶需要清楚的知道，自己的資料庫，在什麼時間，被什麼人，以什麼工具，具體做什麼訪問，又拿到了什麼數據。並且需要知道什麼時候出現了攻擊行為和異常的訪問情況。這些功能，正是合格資料庫審計產品所必須具有的功能。在雲平台上的資料庫主要面臨哪些安全問題？
D. 資料庫對一個國家的經濟文化科技國家安全等有何影響
隨著數據安全法、個人信息保護法的頒布實施，數據安全成為各行業數字化轉型的重要一環，通過資料庫技術創新助力數據安全成為業內熱點。
記者調研采訪發現，面對數據安全合規以及新應用新場景下的安全防護要求，傳統資料庫安全防護理念和技術已經開始轉變。在大數據環境下進行頂層設計、標准制訂，對各大數據組件進行安全審計、訪問控制與風險識別，針對結構化與非結構化數據的安全脫敏、加密安全與隱私防護等，都是當前資料庫安全防護新趨勢的重要問題。
多因素驅動資料庫安全發展
近年來，我國數字經濟蓬勃發展。最新發布的《中國互聯網發展報告2021》顯示，2020年我國數字經濟規模達到39.2萬億元，佔GDP比重達38.6%。
「只有保障數據安全，才能築牢數字經濟發展的底線。」達夢資料庫高級副總經理付銓表示，數據是數字經濟的重要生產資料，是國家核心戰略資源和社會重要財富。同時，數據安全問題是關乎數字經濟健康有序可持續發展的重大問題。
綠盟科技集團副總裁李晨認為，資料庫安全發展主要有兩個驅動因素，一是資料庫本身的發展促使資料庫安全技術發展，二是數據安全相關法律法規和標准規范對資料庫安全防護提出新的需求。從技術發展看，大規模的數據存儲和處理需求，使得大數據、數據倉庫、數據湖以及數據中台得到推廣，並應用於分布式資料庫、雲端資料庫等很多場景。從數據安全法律法規看，繼等級保護2.0系列標准提出大數據應用場景的安全防護參考後，數據安全法和個人信息保護法又相繼頒布實施，將數據安全要求提高到法律的高度。
在中國信通院資料庫應用創新實驗室、中國通信標准化協會大數據技術標准推進委員會近日舉辦的「資料庫安全防護新趨勢」沙龍上，清華大學計算機系長聘教授李國良表示，標准有助於落實產業政策，促進企業發展。希望更多企業重視相關工作，共同為資料庫安全的發展做出貢獻。
據中國信通院雲大所工程師劉思源介紹，中國信通院深耕資料庫領域標准研製、產業研究、政策支撐、評測評估等，依託中國通信標准化協會大數據技術標准推進委員會，已牽頭編制近10項資料庫領域行業標准和若干團體標准，累計發布資料庫白皮書和研究報告近10本，並定期發布評測評估觀察，為遴選優質標的提供重要依據。
資料庫安全保障網路安全
資料庫安全防護是數據安全治理體系的一部分。李晨表示，綠盟科技從數據安全建設頂層設計出發，提出「一個中心，四個領域，五個階段」的數據安全體系建設思路。以數據安全防護為中心，在組織建設、制度流程、技術工具和人員能力四個領域同時開展建設工作，通過「知、識、控、察、行」五個步驟進行數據安全落地建設。僅就資料庫安全技術而言，綠盟科技有數據分類分級、審計與訪問控制、脫敏、水印、脫敏後風險評估、數據防護與態勢感知和隱私計算相關技術等。
付銓表示，在信息技術快速發展的背景下，需要在網路信息安全關鍵技術上有更大突破，前提是獨立研發，掌握核心技術。在安全問題上，只有資料庫沒有安全問題，數據才不會泄露或丟失，信息安全才能得到保障。可以說，只有底層的資料庫安全了，網路安全才有保障。
據介紹，達夢資料庫研發的數據共享集群實現了國產資料庫在共享存儲集群方面的突破，在性能上與國際同類產品持平。公司產品廣泛應用於金融、能源、電信等50多個重要領域。
構築多維度立體化安全防線
「隨著數據價值重要性的凸顯以及未來開放性環境下的安全風險日益突出，資料庫需要圍繞系統整體韌性能力和數據端到端全生命周期安全構建系統整體外部感知能力和機密計算能力，並完善內核審計追溯能力。」華為技術有限公司資料庫技術專家朱金偉說。
勒索病毒是當前受到關注的網路安全風險。美創科技產品和解決方案中心總監胡大海表示，為有效抵禦勒索病毒威脅，美創科技從防範實踐出發，以「零信任」安全理念為基礎，推出「勒索防禦產品+安全保險+容災備份」三位一體的勒索病毒風險解決方案，為機構數據安全構築起多維度、立體化的安全防線。完善的數據容災備份建設可以在攻擊發生前對數據進行備份，在攻擊發生後對數據進行恢復，最大程度降低由勒索病毒加密、竊取數據造成的數據丟失乃至業務中斷等影響。
據騰訊雲計算技術有限公司資料庫高級產品經理程昌明介紹，目前騰訊雲資料庫已經能夠從數據沉澱、業務學習、特徵總結、風險模型、人為中心以及行為分析等方面，基於大數據分析進行安全治理。
E. 在IT項目建設中，如何保證資料庫安全性
#雲原生背景#
雲計算是信息技術發展和服務模式創新的集中體現，是信息化發展的重要變革和必然趨勢。隨著「新基建」加速布局，以及企業數字化轉型的逐步深入，如何深化用雲進一步提升雲計算使用效能成為現階段雲計算發展的重點。雲原生以其高效穩定、快速響應的特點極大地釋放了雲計算效能，成為企業數字業務應用創新的原動力，雲原生進入快速發展階段，就像集裝箱加速貿易全球化進程一樣，雲原生技術正在助力雲計算普及和企業數字化轉型。
雲原生計算基金會（CNCF）對雲原生的定義是：雲原生技術有利於各組織在公有雲、私有雲和混合雲等新型動態環境中，構建和運行可彈性擴展的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式編程API。
#雲安全時代市場發展#
雲安全幾乎是伴隨著雲計算市場而發展起來的，雲基礎設施投資的快速增長，無疑為雲安全發展提供土壤。根據 IDC 數據，2020 年全球雲安全支出占雲 IT 支出比例僅為 1.1%，說明目前雲安全支出遠遠不夠，假設這一比例提升至 5%，那麼2020 年全球雲安全市場空間可達 53.2 億美元，2023 年可達 108.9 億美元。
海外雲安全市場：技術創新與兼並整合活躍。整體來看，海外雲安全市場正處於快速發展階段，技術創新活躍，兼並整合頻繁。一方面，雲安全技術創新活躍，並呈現融合發展趨勢。例如，綜合型安全公司 PaloAlto 的 Prisma 產品線將 CWPP、CSPM 和 CASB 三個雲安全技術產品統一融合，提供綜合解決方案及 SASE、容器安全、微隔離等一系列雲上安全能力。另一方面，新興的雲安全企業快速發展，同時，傳統安全供應商也通過自研+兼並的方式加強雲安全布局。
國內雲安全市場：市場空間廣闊，尚處於技術追隨階段。市場規模上，根據中國信通院數據，2019 年我國雲計算整體市場規模達 1334.5億元，增速 38.6%。預計 2020-2022 年仍將處於快速增長階段，到 2023 年市場規模將超過 3754.2 億元。中性假設下，安全投入占雲計算市場規模的 3%-5%，那麼 2023 年中國雲安全市場規模有望達到 112.6 億-187.7 億元。技術發展上，中國在雲計算的發展階段和雲原生技術的程度上與海外市場還有一定差距。國內 CWPP 技術應用較為廣泛，對於 CASB、CSPM 一些新興的雲安全技術應用較少。但隨著國內公有雲市場的加速發展，雲原生技術的應用越來越廣泛，我們認為CASB、SCPM、SASE 等新興技術在國內的應用也將越來越廣泛。
#雲上安全呈原生化發展趨勢#
雲原生技術逐漸成為雲計算市場新趨勢，所帶來的安全問題更為復雜。以容器、服務網格、微服務等為代表的雲原生技術，正在影響各行各業的 IT 基礎設施、平台和應用系統，也在滲透到如 IT/OT 融合的工業互聯網、IT/CT 融合的 5G、邊緣計算等新型基礎設施中。隨著雲原生越來越多的落地應用，其相關的安全風險與威脅也不斷的顯現出來。Docker/Kubernetes 等服務暴露問題、特斯拉 Kubernetes 集群挖礦事件、Docker Hub 中的容器鏡像被「投毒」注入挖礦程序、微軟 Azure 安全中心檢測到大規模 Kubernetes 挖礦事件、Graboid 蠕蟲挖礦傳播事件等一系列針對雲原生的安全攻擊事件層出不窮。
從各種各樣的安全風險中可以一窺雲原生技術的安全態勢，雲原生環境仍然存在許多安全問題亟待解決。在雲原生技術的落地過程中，安全是必須要考慮的重要因素。
#雲原生安全的定義#
國內外各組織、企業對雲原生安全理念的解釋略有差異，結合我國產業現狀與痛點，雲原生與雲計算安全相似，雲原生安全也包含兩層含義：「面向雲原生環境的安全」和「具有雲原生特徵的安全」。
面向雲原生環境的安全，其目標是防護雲原生環境中的基礎設施、編排系統和微服務的安全。這類安全機制，不一定具備雲原生的特性（比如容器化、可編排），它們可以是傳統模式部署的，甚至是硬體設備，但其作用是保護日益普及的雲原生環境。
具有雲原生特徵的安全，是指具有雲原生的彈性敏捷、輕量級、可編排等特性的各類安全機制。雲原生是一種理念上的創新，通過容器化、資源編排和微服務重構了傳統的開發運營體系，加速業務上線和變更的速度，因而，雲原生系統的種種優良特性同樣會給安全廠商帶來很大的啟發，重構安全產品、平台，改變其交付、更新模式。
#雲原生安全理念構建#
為緩解傳統安全防護建設中存在的痛點，促進雲計算成為更加安全可信的信息基礎設施，助力雲客戶更加安全的使用雲計算，雲原生安全理念興起，國內外第三方組織、服務商紛紛提出以原生為核心構建和發展雲安全。
Gartner提倡以雲原生思維建設雲安全體系
基於雲原生思維，Gartner提出的雲安全體系覆蓋八方面。其中，基礎設施配置、身份和訪問管理兩部分由雲服務商作為基礎能力提供，其它六部分，包括持續的雲安全態勢管理，全方位的可視化、日誌、審計和評估，工作負載安全，應用、PaaS 和 API 安全，擴展的數據保護，雲威脅檢測，客戶需基於安全產品實現。
Forrester評估公有雲平台原生安全能力
Forrester認為公有雲平台原生安全（Public cloud platform native security, PCPNS）應從三大類、37 個方面去衡量。從已提供的產品和功能，以及未來戰略規劃可以看出，一是考察雲服務商自身的安全能力和建設情況，如數據中心安全、內部人員等，二是雲平台具備的基礎安全功能，如幫助和文檔、授權和認證等，三是為用戶提供的原生安全產品，如容器安全、數據安全等。
安全狗以4項工作防護體系建設雲原生安全
（1）結合雲原生技術的具體落地情況開展並落實最小許可權、縱深防禦工作，對於雲原生環境中的各種組成部分，均可貫徹落實「安全左移」的原則，進行安全基線配置，防範於未然。而對於微服務架構Web應用以及Serverless應用的防護而言，其重點是應用安全問題。
（2）圍繞雲原生應用的生命周期來進行DevSecOps建設，以當前的雲原生環境的關鍵技術棧「K8S + Docker」舉例進行分析。應該在容器的全生命周期注重「配置安全」，在項目構建時注重「鏡像安全」，在項目部署時注重「容器准入」，在容器的運行環境注重雲計算的三要素「計算」「網路」以及「存儲」等方面的安全問題。
（3）圍繞攻擊前、中、後的安全實施准則進行構建，可依據安全實施准則對攻擊前、中、後這三個階段開展檢測與防禦工作。
（4）改造並綜合運用現有雲安全技術，不應將「雲原生安全」視為一個獨立的命題，為雲原生環境提供更多支持的主機安全、微隔離等技術可賦能於雲原生安全。
#雲原生安全新型風險#
雲原生架構的安全風險包含雲原生基礎設施自身的安全風險，以及上層應用雲原生化改造後新增和擴大的安全風險。雲原生環境面臨著嚴峻的安全風險問題。攻擊者可能利用的重要攻擊麵包括但不限於：容器安全、編排系統、軟體供應鏈等。下面對重要的攻擊面安全風險問題進行梳理。
#雲原生安全問題梳理#
問題1：容器安全問題
在雲原生應用和服務平台的構建過程中，容器技術憑借高彈性、敏捷的特性，成為雲原生應用場景下的重要技術支撐，因而容器安全也是雲原生安全的重要基石。
（1）容器鏡像不安全
Sysdig的報告中提到，在用戶的生產環境中，會將公開的鏡像倉庫作為軟體源，如最大的容器鏡像倉庫Docker Hub。一方面，很多開源軟體會在Docker Hub上發布容器鏡像。另一方面，開發者通常會直接下載公開倉庫中的容器鏡像，或者基於這些基礎鏡像定製自己的鏡像，整個過程非常方便、高效。然而，Docker Hub上的鏡像安全並不理想，有大量的官方鏡像存在高危漏洞，如果使用了這些帶高危漏洞的鏡像，就會極大的增加容器和主機的入侵風險。目前容器鏡像的安全問題主要有以下三點：
1.不安全的第三方組件
在實際的容器化應用開發過程當中，很少從零開始構建鏡像，而是在基礎鏡像之上增加自己的程序和代碼，然後統一打包最終的業務鏡像並上線運行，這導致許多開發者根本不知道基礎鏡像中包含多少組件，以及包含哪些組件，包含的組件越多，可能存在的漏洞就越多。
2.惡意鏡像
公共鏡像倉庫中可能存在第三方上傳的惡意鏡像，如果使用了這些惡意鏡像來創建容器後，將會影響容器和應用程序的安全
3.敏感信息泄露
為了開發和調試的方便，開發者將敏感信息存在配置文件中，例如資料庫密碼、證書和密鑰等內容，在構建鏡像時，這些敏感信息跟隨配置文件一並打包進鏡像，從而造成敏感信息泄露
（2）容器生命周期的時間短
雲原生技術以其敏捷、可靠的特點驅動引領企業的業務發展，成為企業數字業務應用創新的原動力。在容器環境下，一部分容器是以docker的命令啟動和管理的，還有大量的容器是通過Kubernetes容器編排系統啟動和管理，帶來了容器在構建、部署、運行，快速敏捷的特點，大量容器生命周期短於1小時，這樣一來容器的生命周期防護較傳統虛擬化環境發生了巨大的變化，容器的全生命周期防護存在很大變數。對防守者而言，需要採用傳統異常檢測和行為分析相結合的方式，來適應短容器生命周期的場景。
傳統的異常檢測採用WAF、IDS等設備，其規則庫已經很完善，通過這種檢測方法能夠直觀的展示出存在的威脅，在容器環境下，這種方法仍然適用。
傳統的異常檢測能夠快速、精確地發現已知威脅，但大多數未知威脅是無法通過規則庫匹配到的，因而需要通過行為分析機制來從大量模式中將異常模式分析出來。一般來說，一段生產運營時間內的業務模式是相對固定的，這意味著，業務行為是可以預測的，無論啟動多少個容器，容器內部的行為總是相似的。通過機器學習、採集進程行為，自動構建出合理的基線，利用這些基線對容器內的未知威脅進行檢測。
（3）容器運行時安全
容器技術帶來便利的同時，往往會忽略容器運行時的安全加固，由於容器的生命周期短、輕量級的特性，傳統在宿主機或虛擬機上安裝殺毒軟體來對一個運行一兩個進程的容器進行防護，顯示費時費力且消耗資源，但在黑客眼裡容器和裸奔沒有什麼區別。容器運行時安全主要關注點：
1.不安全的容器應用
與傳統的Web安全類似，容器環境下也會存在SQL注入、XSS、RCE、XXE等漏洞，容器在對外提供服務的同時，就有可能被攻擊者利用，從而導致容器被入侵
2.容器DDOS攻擊
默認情況下，docker並不會對容器的資源使用進行限制，默認情況下可以無限使用CPU、內存、硬碟資源，造成不同層面的DDOS攻擊
（4）容器微隔離
在容器環境中，與傳統網路相比，容器的生命周期變得短了很多，其變化頻率也快很多。容器之間有著復雜的訪問關系，尤其是當容器數量達到一定規模以後，這種訪問關系帶來的東西向流量，將會變得異常的龐大和復雜。因此，在容器環境中，網路的隔離需求已經不僅僅是物理網路的隔離，而是變成了容器與容器之間、容器組與宿主機之間、宿主機與宿主機之間的隔離。
問題2：雲原生等保合規問題
等級保護2.0中，針對雲計算等新技術、新應用領域的個性安全保護需求提出安全擴展要求，形成新的網路安全等級保護基本要求標准。雖然編寫了雲計算的安全擴展要求，但是由於編寫周期很長，編寫時主流還是虛擬化場景，而沒有考慮到容器化、微服務、無服務等雲原生場景，等級保護2.0中的所有標准不能完全保證適用於目前雲原生環境；
通過安全狗在雲安全領域的經驗和具體實踐，對於雲計算安全擴展要求中訪問控制的控制點，需要檢測主機賬號安全，設置不同賬號對不同容器的訪問許可權，保證容器在構建、部署、運行時訪問控制策略隨其遷移；
對於入侵防範制的控制點，需要可視化管理，繪制業務拓撲圖，對主機入侵進行全方位的防範，控制業務流量訪問，檢測惡意代碼感染及蔓延的情況；
鏡像和快照保護的控制的，需要對鏡像和快照進行保護，保障容器鏡像的完整性、可用性和保密性，防止敏感信息泄露。
問題3：宿主機安全
容器與宿主機共享操作系統內核，因此宿主機的配置對容器運行的安全有著重要的影響，比如宿主機安裝了有漏洞的軟體可能會導致任意代碼執行風險，埠無限制開放可能會導致任意用戶訪問的風險。通過部署主機入侵監測及安全防護系統，提供主機資產管理、主機安全加固、風險漏洞識別、防範入侵行為、問題主機隔離等功能，各個功能之間進行聯動，建立採集、檢測、監測、防禦、捕獲一體化的安全閉環管理系統，對主機進行全方位的安全防護，協助用戶及時定位已經失陷的主機，響應已知、未知威脅風險，避免內部大面積主機安全事件的發生。
問題4：編排系統問題
編排系統支撐著諸多雲原生應用，如無服務、服務網格等，這些新型的微服務體系也同樣存在著安全問題。例如攻擊者編寫一段代碼獲得容器的shell許可權，進而對容器網路進行滲透橫移，造成巨大損失。
Kubernetes架構設計的復雜性，啟動一個Pod資源需要涉及API Server、Controller、Manager、Scheler等組件，因而每個組件自身的安全能力顯的尤為重要。API Server組件提供的認證授權、准入控制，進行細粒度訪問控制、Secret資源提供密鑰管理及Pod自身提供安全策略和網路策略，合理使用這些機制可以有效實現Kubernetes的安全加固。
問題5：軟體供應鏈安全問題
通常一個項目中會使用大量的開源軟體，根據Gartner統計至少有95%的企業會在關鍵IT產品中使用開源軟體，這些來自互聯網的開源軟體可能本身就帶有病毒、這些開源軟體中使用了哪些組件也不了解，導致當開源軟體中存在0day或Nday漏洞，我們根本無法獲悉。
開源軟體漏洞無法根治，容器自身的安全問題可能會給開發階段帶的各個過程帶來風險，我們能做的是根據SDL原則，從開發階段就開始對軟體安全性進行合理的評估和控制，來提升整個供應鏈的質量。
問題6：安全運營成本問題
雖然容器的生命周期很短，但是包羅萬象。對容器的全生命周期防護時，會對容器構建、部署、運行時進行異常檢測和安全防護，隨之而來的就是高成本的投入，對成千上萬容器中的進程行為進程檢測和分析，會消耗宿主機處理器和內存資源，日誌傳輸會佔用網路帶寬，行為檢測會消耗計算資源，當環境中容器數量巨大時，對應的安全運營成本就會急劇增加。
問題7：如何提升安全防護效果
關於安全運營成本問題中，我們了解到容器安全運營成本較高，我們該如何降低安全運營成本的同時，提升安全防護效果呢？這就引入一個業界比較流行的詞「安全左移」，將軟體生命周期從左到右展開，即開發、測試、集成、部署、運行，安全左移的含義就是將安全防護從傳統運營轉向開發側，開發側主要設計開發軟體、軟體供應鏈安全和鏡像安全。
因此，想要降低雲原生場景下的安全運營成本，提升運營效率，那麼首先就要進行「安全左移」，也就是從運營安全轉向開發安全，主要考慮開發安全、軟體供應鏈安全、鏡像安全和配置核查：
開發安全
需要團隊關注代碼漏洞，比如使用進行代碼審計，找到因缺少安全意識造成的漏洞和因邏輯問題造成的代碼邏輯漏洞。
供應鏈安全
可以使用代碼檢查工具進行持續性的安全評估。
鏡像安全
使用鏡像漏洞掃描工具持續對自由倉庫中的鏡像進行持續評估，對存在風險的鏡像進行及時更新。
配置核查
核查包括暴露面、宿主機加固、資產管理等，來提升攻擊者利用漏洞的難度。
問題8：安全配置和密鑰憑證管理問題
安全配置不規范、密鑰憑證不理想也是雲原生的一大風險點。雲原生應用會存在大量與中間件、後端服務的交互，為了簡便，很多開發者將訪問憑證、密鑰文件直接存放在代碼中，或者將一些線上資源的訪問憑證設置為弱口令，導致攻擊者很容易獲得訪問敏感數據的許可權。
#雲原生安全未來展望#
從日益新增的新型攻擊威脅來看，雲原生的安全將成為今後網路安全防護的關鍵。伴隨著ATT&CK的不斷積累和相關技術的日益完善，ATT&CK也已增加了容器矩陣的內容。ATT&CK是對抗戰術、技術和常識（Adversarial Tactics, Techniques, and Common Knowledge）的縮寫，是一個攻擊行為知識庫和威脅建模模型，它包含眾多威脅組織及其使用的工具和攻擊技術。這一開源的對抗戰術和技術的知識庫已經對安全行業產生了廣泛而深刻的影響。
雲原生安全的備受關注，使ATTACK Matrix for Container on Cloud的出現恰合時宜。ATT&CK讓我們從行為的視角來看待攻擊者和防禦措施，讓相對抽象的容器攻擊技術和工具變得有跡可循。結合ATT&CK框架進行模擬紅藍對抗，評估企業目前的安全能力，對提升企業安全防護能力是很好的參考。
F. 資料庫需求分析中的安全性完整性怎麼體現
完整性和安全性都是在資料庫編程中可以用編程語句來實現的，在SQL編程中加上完整性約束條件。
樓主說的在需求分析中體現安全性和完整性，這就比較復雜了。
因為第一，普通用戶根本不知道資料庫能幹什麼，不能幹什麼，這樣用戶自己很難確定需求，所表述的需求不清晰，也經常改動，這是資料庫設計很正常的事情；第二，設計人員缺少專業的知識，理解不了用戶所要的需求，這都是在資料庫需求分析中常見的。
因此，為了體現這一方面，資料庫的設計人員應和用戶多多交流、多多溝通，確定用戶真正的需求，是資料庫中的數據達到完整和安全。。。
G. 如何做好MySQL安全策略
摘至網頁鏈接
常見Mysql配置文件：linux系統下是my.conf，windows環境下是my.ini；
資料庫整體安全需求：機密性、完整性、可用性；
下面以mysql 5.7版本為例，介紹mysql常見的安全策略、配置、加固方式等等，有些策略可能只針對Linux操作系統，更多策略可以參考CIS Mysql Benchmark相關文檔：
1、操作系統級別安全配置
1.1不要將資料庫放在系統分區
Windows系統：直接檢查是否將資料庫放置在C盤。
Linux系統：
在終端連接上mysql資料庫，執行如下命令：
show variables where variable_name = 'datadir';
然後返回shell命令行：
df -h <datadir>
其中datadir是上一條命令的返回值。
上述命令的返回值不應是/、/var、/usr
1.2使用專用的最小許可權賬號運行mysql資料庫進程
Windows系統：直接打開任務管理器，查看運行mysql進程的操作系統賬號，不能為administrator賬號。
Linux系統：
Shell命令行運行如下命令：
ps -ef | grep mysql
查看mysql服務的運行賬號是否為root或其他高許可權賬號，如果是的，則需要創建一個非管理員專用賬號來運行mysql服務。
1.3禁止使用mysql命令行歷史記錄
Linux系統：
執行如下命令：
find / -name ".mysql_history"
查看是否存在mysql的歷史命令記錄文件，如果存在，則需要進行如下加固：
（1）刪除.mysql_history文件；
（2）設置環境變數MYSQL_HISTFILE為/dev/null，並添加到shell的初始化腳本中，創建mysql_history到/dev/null的鏈接：
ln -s /dev/null $HOME/.mysql_history
1.4確保MYSQL_PWD環境變數未設置敏感信息
Windows系統下進入cmd命令行，使用如下命令：
Set
查看是否設置了環境變數MYSQL_PWD。
Linux系統下使用如下命令：
grep MYSQL_PWD /proc/*/environ
查看MYSQL_PWD環境變數是否設置了敏感信息。
確認那個配置文件或腳本設置了MYSQL_PWD環境變數。
2、安裝
2.1使用資料庫專用伺服器
使用專用的伺服器安裝mysql服務可以減少mysql服務的攻擊面，盡量卸載或刪除操作系統上的不必要的應用或服務，減少其他應用的安裝可能給mysql的運行帶來的安全風險。
2.2不要復用資料庫賬號
運行mysql服務的操作系統賬號不要用來運行其他應用或服務，這樣可以避免其他應用或伺服器被攻擊給mysql服務帶來影響。
2.3歷史命令行密碼設置為不可見
使用如下命令：
mysql -u admin -p password
連接mysql資料庫服務，退出後查看歷史命令，確認password是否為明文。
建議使用如下命令方式登錄：
（1）先輸入mysql -u admin -p
（2）根據命令行提示輸入密碼；
而不要在一整條命令中輸入密碼。
另外要控制mysql配置文件訪問許可權。
3、文件許可權控制
3.1控制數據目錄的訪問許可權
數據目錄是mysql資料庫存放的位置，在mysql命令行界面下執行如下命令：
show variables where variable_name = 'datadir';
在終端命令行下執行如下命令：
ls -l <datadir>/.. | egrep "^d[r|w|x]{3}------s*.s*mysqls*mysqls*d*.*mysql"
其中<datadir>是第一條命令的執行結果
如果存在問題，linux環境下在終端執行如下命令進行加固：
chmod 700 <datadir>
chown mysql:mysql <datadir>
3.2控制二進制日誌文件的許可權
mysql的運行會產生很多日誌，例如二進制日誌、錯誤日誌、慢查詢日誌等等，Mysql命令行下執行如下命令：
show variables like 'log_bin_basename';
在終端命令行執行如下命令：
ls <log_bin_basename>.*
對於發現的每一個文件，執行如下命令：
ls -l <log_bin_basename.nnnnn> | egrep "^-[r|w]{2}-[r|w]{2}----s*.*$"
根據輸出確認日誌文件的許可權設置是否存在問題。
對於每個日誌文件，修改其許可權和屬組如下：
chmod 660 <log file>
chown mysql:mysql <log file>
3.3控制錯誤日誌文件的許可權
Mysql命令行下執行如下命令：
show variables like 'log_error';
在終端命令行執行如下命令：
ls <log_error>.*
對於發現的每一個文件，執行如下命令：
ls -l <log_error> | egrep "^-[r|w]{2}-[r|w]{2}----s*.*$"
根據輸出確認日誌文件的許可權設置是否存在問題。
對於每個日誌文件，修改其許可權和屬組如下：
chmod 660 <log file>
chown mysql:mysql <log file>
3.4控制慢查詢日誌文件的許可權
Mysql命令行下執行如下命令：
show variables like 'slow_query_log_file';
在終端命令行執行如下命令：
ls <slow_query_log_file>.*
對於發現的每一個文件，執行如下命令：
ls -l <slow_query_log_file> | egrep "^-[r|w]{2}-[r|w]{2}----s*.*$"
根據輸出確認日誌文件的許可權設置是否存在問題。
對於每個日誌文件，修改其許可權和屬組如下：
chmod 660 <log file>
chown mysql:mysql <log file>
3.5控制通用日誌文件的許可權
Mysql命令行下執行如下命令：
show variables like 'general_log_file';
在終端命令行執行如下命令：
ls <general_log_file>.*
對於發現的每一個文件，執行如下命令：
ls -l <general_log_file> | egrep "^-[r|w]{2}-[r|w]{2}----s*.*$"
根據輸出確認日誌文件的許可權設置是否存在問題。
對於每個日誌文件，修改其許可權和屬組如下：
chmod 660 <log file>
chown mysql:mysql <log file>
3.6控制審計日誌文件的許可權
Mysql命令行下執行如下命令：
show global variables where variable_name = 'audit_log_file';
在終端執行如下命令：
ls -l <audit_log_file> | egrep "^-rw[-x]rw[-x][-r][-w][-x][ ]*[0-9][ ]*mysql[
]*mysql.*$"
根據輸出確認日誌文件的許可權設置是否存在問題。
對於每個日誌文件，修改其許可權和屬組如下：
chmod 660 <audit_log_file>
chown mysql:mysql <audit_log_file>
4、通用安全
4.1安裝最新的補丁
在mysql命令行下查詢MySQL的版本：
SHOW VARIABLES WHERE Variable_name LIKE "version";
確認是否由需要安裝的補丁包，如果有請安裝。
4.2刪除test資料庫
Mysql資料庫默認安裝好後，存在一個名為test的資料庫，如果存在，請執行如下命令刪除：
Drop database 「test」
4.3確保讀取本地文件的參數設置為失效
Mysql命令行下，使用如下命令：
SHOW VARIABLES WHERE Variable_name = 'local_infile';
查看結果是否為OFF。
如果該命令為ON，則資料庫用戶可以通過LOAD DATA INFILE 或者SELECT local_file讀取到資料庫所在操作系統本地的文件，在這種情況下，需要在mysql配置文件中新增一行：
Local-infile=0；
然後重啟資料庫服務。
5、許可權配置
5.1控制可以訪問所有資料庫的賬號
Mysql資料庫下的user表和db表中存放著可以授予資料庫用戶的許可權，確保只有管理員賬號才能訪問所有資料庫。可以訪問mysql資料庫的用戶或許可以查看密碼哈希值、修改用戶許可權等等。
使用如下sql語句：
SELECT user, hostFROM mysql.user
WHERE (Select_priv = 'Y')OR (Insert_priv = 'Y')OR (Update_priv = 'Y')
OR (Delete_priv = 'Y')OR (Create_priv = 'Y')OR (Drop_priv = 'Y');
SELECT user, hostFROM mysql.dbWHERE db = 'mysql'
AND ((Select_priv = 'Y')OR (Insert_priv = 'Y')OR (Update_priv = 'Y')
OR (Delete_priv = 'Y')OR (Create_priv = 'Y')OR (Drop_priv = 'Y'));
確保返回結果只能是資料庫管理員賬號。
5.2限制非管理員用戶的許可權
Mysql.user表中的許可權列有：
file_priv：表示是否允許用戶讀取資料庫所在主機的本地文件；
Process：表示是否允許用戶查詢所有用戶的命令執行信息；
Super_priv：表示用戶是否有設置全局變數、管理員調試等高級別許可權；
Shutdown_priv：表示用戶是否可以關閉資料庫；
Create_user_priv：表示用戶是否可以創建或刪除其他用戶；
Grant_priv：表示用戶是否可以修改其他用戶的許可權；
應確保只有資料庫管理員才有上述許可權，使用如下sql語句查看擁有各個許可權的資料庫賬號：
select user, host from mysql.user where File_priv = 'Y';
select user, host from mysql.user where Process_priv = 'Y';
select user, host from mysql.user where Process_priv = 'Y';
SELECT user, host FROM mysql.user WHERE Shutdown_priv = 'Y';
SELECT user, host FROM mysql.user WHERE Create_user_priv = 'Y';
SELECT user, host FROM mysql.user WHERE Grant_priv = 'Y';
SELECT user, host FROM mysql.db WHERE Grant_priv = 'Y';
確保查詢結果中不存在非管理員用戶。
如果存在非管理員用戶，使用如下命令進行許可權回收：
REVOKE FILE ON *.* FROM '<user>';
REVOKE PROCESS ON *.* FROM '<user>';
REVOKE SUPER ON *.* FROM '<user>';
REVOKE SHUTDOWN ON *.* FROM '<user>';
REVOKE CREATE USER ON *.* FROM '<user>';
REVOKE GRANT OPTION ON *.* FROM <user>;
其中user為上述查詢到的非管理員用戶。
5.3合理控制DML/DDL操作授權
DML/DDL語句包括創建或修改資料庫結構的許可權，例如insert、update、delete、create、drop和alter語句，在任何資料庫中都要控制用戶的此類許可權，確保只授權給有業務需求的非管理員用戶。Mysql命令行下執行如下命令：
SELECT User,Host,DbFROM mysql.dbWHERE Select_priv='Y'
OR Insert_priv='Y'OR Update_priv='Y'OR Delete_priv='Y'OR Create_priv='Y'
OR Drop_priv='Y'OR Alter_priv='Y';
上述查詢到的用戶只能對特地的資料庫才有相關的許可權，使用如下命令進行相關許可權的回收：
REVOKE SELECT ON <host>.<database> FROM <user>;
REVOKE INSERT ON <host>.<database> FROM <user>;
REVOKE UPDATE ON <host>.<database> FROM <user>;
REVOKE DELETE ON <host>.<database> FROM <user>;
REVOKE CREATE ON <host>.<database> FROM <user>;
REVOKE DROP ON <host>.<database> FROM <user>;
REVOKE ALTER ON <host>.<database> FROM <user>;
其中<user>為查詢到的未授權的用戶，host為相關主機，database為相關資料庫。
6、審計和日誌
6.1開啟錯誤日誌審計功能
錯誤日誌包括資料庫運行和停止過程中的一系列活動信息，有助於分析資料庫運行過程中的一些異常活動，一般情況下需要開啟錯誤日誌記錄功能，使用如下命令查詢：
SHOW variables LIKE 'log_error';
確保返回結果為非空，如果為空，需要在mysql資料庫配置文件中增加相關配置。
6.2確保日誌存放在非系統區域
日誌文件隨著資料庫的運行會不斷增加，如果存放在系統區域，則會影響系統的正常運行，使用如下命令進行查詢：
SELECT @@global.log_bin_basename;
確保返回結果不是如下路徑：/、/var、/usr
6.3關閉原始日誌功能
原始日誌選項會決定一些敏感信息是否會被明文寫進日誌中，例如查詢日誌、慢查詢日誌、二進制日誌，確保資料庫配置文件中存在如下配置項：
Log-raw = OFF
7、認證
7.1 Old_passwords環境變數設置
Old_passwords決定了使用PASSWORD()函數和IDENTIFIED BY、CREATE USER、GRANT等語句是時的hash演算法：
0 - authenticate with the mysql_native_password plugin
1 - authenticate with the mysql_old_password plugin
2 - authenticate with the sha256_password plugin
設置為mysql_old_password代表弱hash演算法，可以快速通過密碼字典進行暴力破解。使用如下命令查詢相關值：
SHOW VARIABLES WHERE Variable_name = 'old_passwords';
確保返回值不為1。
7.2 secure_auth選項設置
如果客戶端採用Old_passwords發起連接請求，如果伺服器端設置了secure_auth，則客戶端會拒絕連接請求，可以根據安全需求在配置文件中做相應配置。
7.3密碼保存
確保密碼沒有明文保存在全局配置文件中。
7.4確保所有用戶都要求使用非空密碼登錄
執行如下語句查詢是否有用戶不需要密碼即可登錄：
SELECT User,host
FROM mysql.user
WHERE (plugin IN('mysql_native_password', 'mysql_old_password')
AND (LENGTH(Password) = 0
OR Password IS NULL))
OR (plugin='sha256_password' AND LENGTH(authentication_string) = 0);
7.5不存在空賬號
使用如下命令查詢是否存在空賬號：
SELECT user,host FROM mysql.user WHERE user = '';
8、網路設置
如果mysql資料庫伺服器與應用是跨信任域部署的，則需要考慮在資料庫伺服器與應用伺服器之間建立ssl通道進行數據傳輸，不過這種場景一般很少見，在此不詳細描述。
9、資料庫備份
H. 以數據為中心的安全是否可以滿足現在的數據安全需求
我覺得基於「安全體系以數據為中心」的數據安全理念則更貼近安全目標，因為數據安全主要依靠的是一種「協議解析」技術，對資料庫流量協議數據包進行全協議解碼，從資料庫協議、應用協議中抽取出更為細粒度的SQL語句以及應用客戶端、訪問源IP、目標資料庫IP、資料庫用戶、資料庫實例等信息，以該技術為基礎進行數據級的細粒度控制手段，才能滿足企業內部數據傳輸、數據訪問、數據處理的更高細粒度的訪問准入控制要求。