SaaS具有以下幾方面的特點：

• 多重租賃性和自定制性：SaaS提供商只需提供一套軟件系統就能夠同時支持多個租戶。客戶可結合實際需求，定制個性化的SaaS軟件。

• 可擴展性和靈活應變性：SaaS可以通過參數應用、自定制空間、集成器，把多個不同的在線應用軟件服務重新整合，形成新的軟件服務，具有良好的可擴展性。此外，對SaaS應用程序的使用是動態的，用戶能夠根據市場需求變化，隨時對應用軟件作出調整，以應對新需求。

• 經濟性：SaaS提供商只需要維護和升級一套軟件系統，無須提供售后技術服務，從而降低了軟件的維護和售后服務費用。用戶以租賃的方式在線使用SaaS軟件，不用購買軟硬件、建設機房、招聘IT人員等，減少了前期投資、設備維護費、軟件授權費等。

• 在線工作性：SaaS通過互聯網提供軟件托管服務，簡單易用。在線軟件一般容易操作，在服務器端自動升級，無須安裝任何插件或軟件；不需要專職人員維護，隨時隨處可以操作，從而為用戶帶來了極大的便利。

• 可配置性：在SaaS模式下，所有實例都使用相同的代碼實施，供應商提供詳細的配置選擇，用戶可以根據自己的實際需要選擇配置。

• 云部署：SaaS是一種基于云服務的應用產品，因此整個產品完全不適用于傳統軟件的本地部署模式。

• 網絡供應(分發)：呼應云部署。因為部署在云端，每個客戶都必須通過互聯網分發產品。

• 集中托管：這個概念的衍生品叫做多租戶單實例，可以簡單理解為不同客戶的數據沒有物理隔離。相應的單租戶多實例概念是近期流行的私有云部署。

• 按需供應：這一特點明顯針對中小企業，因為只有中小企業的需求才會在短時間內發生很大變化。當然，按需供應也是基于多租戶訂單實例的自然產物。房東只需不斷為有需要的租戶開辟現有空間。

• 服務特性：SaaS使得軟件以互聯網為載體的服務形式被客戶使用，所以服務合約的簽定、服務使用的計量、在線服務質量的保證、服務費用的收取等等問題都必須考慮。而這些問題通常是傳統軟件沒有考慮到的。

• 高效的多用戶支持特性：高效的多客戶支持則是設計基于SaaS模式的系統中最為重要的一環。比如說當一個用戶試圖通過某個基于SaaS模式的客戶關系管理應用來訪問本公司的客戶數據時，它所連接的這一基于SaaS模式的客戶關系管理應用可能正同時被來自不同企業的成百上千個終端用戶所使用，此時所有用戶完全不知道其他并發用戶訪問的存在。這種在SaaS應用中極為常見的場景就要求基于SaaS模式的系統可以支持在多用戶間最大程度共享資源的同時嚴格區分和隔離屬于不同客戶的數據。

信息安全等級保護工作流程包括:

1. 定級：信息系統運營使用單位按照等級保護管理辦法和定級指南，自主確定信息系統的安全保護等級。有上級主管部門的，應當經上級主管部門審批。跨省或全國統一聯網運行的信息系統可以由其主管部門統一確定安全保護等級。雖然說的是自主定級，但是也得根據系統實際情況去定級，有行業指導文件的根據指導文件來，沒有文件的根據定級指南來，總之一句話合理定級，該是幾級就是幾級，不要定的高也不要定的低。

2. 備案：第二級以上信息系統定級單位到所在地所在地設區的市級以上公安機關辦理備案手續。省級單位到省公安廳網安總隊備案，各地市單位一般直接到市級網安支隊備案，也有部分地市區縣單位的定級備案資料是先交到區縣公安網監大隊的，具體根據各地市要求來。備案的時候帶上定級資料去網安部門，一般兩份紙質文檔，一份電子檔，紙質的首頁加蓋單位公章。

3. 系統安全建設：信息系統安全保護等級確定后，運營使用單位按照管理規范和技術標準，選擇管理辦法要求的信息安全產品，建設符合等級要求的信息安全設施，建立安全組織，制定并落實安全管理制度。

4. 等級測評：信息系統建設完成后，運營使用單位選擇符合管理辦法要求的檢測機構，對信息系統安全等級狀況開展等級測評。測評完成之后根據發現的安全問題及時進行整改，特別是高危風險。測評的結論分為：不符合、基本符合、符合。當然符合基本是不可能的，那是理想狀態。

5. 監督檢查：公安機關依據信息安全等級保護管理規范及《網絡安全法》相關條款，監督檢查運營使用單位開展等級保護工作，定期對信息系統進行安全檢查。運營使用單位應當接受公安機關的安全監督、檢查、指導，如實向公安機關提供有關材料。

如果您的網絡配置正確（許多默認的現代配置默認情況下會鎖定端口），則它們將很難進入，但是，如果他們具有知識和持久性，則有可能。

如果您確實有一些開放的端口和漏洞，他們可以在計算機上執行代碼并在計算機連接到網絡時對其進行控制。

或者，可能會發生DDoS（分布式拒絕服務）攻擊，如果路由器沒有完全使您脫機，則會使數據包超載，從而降低網絡速度。

商用密碼應用安全性評估（簡稱“密評”），是指在采用商用密碼技術、產品和服務集成建設的網絡和信息系統中，對其密碼應用的合規性、正確性和有效性進行評估。密評工作主要包括兩部分內容：

方案評估階段

對于新建/改造信息系統，密碼應用建設方案/改造方案，一般由責任單位組織商用密碼從業單位編寫, 包括：《密碼應用解決方案》、《實施方案》和《應急處置方案》。責任單位編寫密碼應用建設方案/改造方案后，應委托測評機構對方案進行評估。

系統評估階段

依據GM/T0054-2018《信息系統密碼應用基本要求》等標準，系統評估主要從物理和環境、網絡和通信、設備和計算、應用和數據、密鑰管理、安全管理等方面開展。

測評機構完成系統評估后，出具評估報告。在密評活動結束30個工作日內，將評估結果報密碼管理部門等相關部門備案。

評估密碼系統安全性主要有三種方法：

• 無條件安全性：這種評價方法考慮的是假定攻擊者擁有無限的計算資源，但仍然無法破譯該密碼系統。

• 計算安全性：這種方法是指如果使用目前最好的方法攻破它所需要的計算資源遠遠超出攻擊者擁有的計算資源，則可以認為這個密碼系統是安全的。

• 可證明安全性：這種方法是將密碼系統的安全性歸結為某個經過深入研究的困難問題（如大整數素因子分解、計算離散對數等）。這種評估方法存在的問題是它只說明了這個密碼方法的安全性與某個困難問題相關，沒有完全證明問題本身的安全性，并給出它們的等價性證明。

不安全的無線網絡可能造成服務丟失或是被利用來對其他網絡發起攻擊，或者個人信息泄露。為了避免一些無線網絡安全漏洞，我們應該：

改變無線路由口令

為無線路由的互聯網訪問設置一個口令至關重要，一個強口令有助于無線網絡的安全，但不要使用原始無線路由器的默認口令，建議更改較為復雜的口令避免簡單被攻破。

更改IP地址設置

路由器制造商為每一個路由器都設置了相同的IP地址。例如TP-link路由器的初始化IP地址為192.168.1.1。這些地址是公開的，眾所周知的，如果知道了你所使用的路由器的制造商和類型，有意者就可以輕易地獲取你的IP地址。因而，應該把更改IP地址，能夠使入侵者不容易猜到IP地址。

無線加密協議

無線加密協議(WEP) 是無線網絡上信息加密的一種標準方法。現在出產的無線路由器幾乎都向用戶提供加密數據的選擇， Wi-Fi保護訪問技術(WPA和WPA 2) 要比WEP協議更加強健， 因此在保障無線通信安全方面作用更大，并且密碼建議采用大小寫字母，數字和符號組成。

MAC地址過濾

這種功能是通過比較試圖連接到路由器的設備MAC地址和路由器所保存設備的MAC地址而實現的。因此， 通過啟用這種特性， 并且只告訴路由器本單位或家庭中無線設備的MAC地址， 我們就可以防止他人盜用自己的互聯網連接，從而提升安全性。

非使用時關閉無線網絡

如果用戶的無線網絡并不需要每周的24小時都提供服務，可以通過關閉它而減少被黑客們利用的機會，但對一個系統安全性的最重大改進措施之一就是直接關閉它，可能對于企業來說，關閉是不可能的，但是對于家用來說還是十分有必要的，因為沒有任何人可以訪問一種并不存在或打開服務。

養成監視網絡的習慣

用戶應當養成收集有關掃描和訪問企圖的日志，并利用現有的大量統計數字生成工具，以便于將這些日志變為更有用的信息。及時有效的查看是否有不明入侵者侵入，馬上采取手段制止，使用最有效的加密手段，更改網絡密碼，避免造成更大損失。

禁止SSID廣播

SSID是無線接入的身份標識符， 用戶用它來建立與接入點之間的連接。你需要給你的每個無線接入點設置一個唯一并且難以推測的SSID， 或者干脆禁止廣播SSID， 這樣非連接用戶， 無法找到你的網絡信息。

僅在某些時段允許互聯網訪問

如果你有規律的上網習慣，可以設定對互聯網的訪問限制在一天的某些時段。例如你是上班族，你一天8小時在公司，周末放假，你可以限制上網在早8點到晚5點，周末不限制，這樣可以有效的防止盜取手段。

網絡信息安全數據面臨以下大數據化挑戰：

• 數據越來越多：網絡已經從吉比特每秒邁向了萬兆比特每秒的速率，網絡安全設備要分析的數據分組數據量急劇上升。同時，隨著安全防御的縱深化，安全監測的內容不斷細化，除了傳統的攻擊監測，還出現了應用監測、用戶行為監測等。此外，隨著APT等新型威脅的興起，全分組捕獲技術逐步應用，海量數據處理問題也日益凸顯。

• 處理越來越快：對于網絡設備而言，包處理和轉發的速度需要更快；對于安全管理平臺、事件分析平臺而言，數據源的事件發送速率越來越快。因此，對安全數據處理的性能將直接影響大數據的服務質量。

• 形態越來越泛：除了協議數據分組、設備日志數據，安全信息還涉及漏洞信息、配置信息、身份與訪問信息、用戶行為信息、應用信息、業務信息、外部情報信息、網絡環境數據等等。針對安全數據形態多樣化、非結構化的發展趨勢，統一的數據表述方法也變得越來越關鍵。

• 大數據本身容易遭受異常流量攻擊：大數據所存儲的數據非常巨大，往往采用分布式的方式進行存儲，而正是由于這種存儲方式，存儲的路徑視圖相對清晰，而數據量過大，導致數據保護，相對簡單，黑客較為輕易利用相關漏洞，實施不法操作，造成安全問題。由于大數據環境下終端用戶非常多，且受眾類型較多，對客戶身份的認證環節需要耗費大量處理能力。由于APT攻擊具有很強的針對性，且攻擊時間長，一旦攻擊成功，大數據分析平臺輸出的最終數據均會被獲取，容易造成的較大的信息安全隱患。

• 容易產生信息泄露：大數據平臺的信息泄露風險在對大數據進行數據采集和信息挖掘的時候，要注重用戶隱私數據的安全問題，在不泄露用戶隱私數據的前提下進行數據挖掘。需要考慮的是在分布計算的信息傳輸和數據交換時保證各個存儲點內的用戶隱私數據不被非法泄露和使用是當前大數據背景下信息安全的主要問題。同時，當前的大數據數據量并不是固定的，而是在應用過程中動態增加的，但是，傳統的數據隱私保護技術大多是針對靜態數據的，所以，如何有效地應對大數據動態數據屬性和表現形式的數據隱私保護也是要注重的安全問題。最后，大數據的數據遠比傳統數據復雜，現有的敏感數據的隱私保護是否能夠滿足大數據復雜的數據信息也是應該考慮的安全問題。

• 傳輸過程中存在安全隱患：數據生命周期安全問題。伴隨著大數據傳輸技術和應用的快速發展，在大數據傳輸生命周期的各個階段、各個環節，越來越多的安全隱患逐漸暴露出來。比如，大數據傳輸環節，除了存在泄漏、篡改等風險外，還可能被數據流攻擊者利用，數據在傳播中可能出現逐步失真等。又如，大數據傳輸處理環節，除數據非授權使用和被破壞的風險外，由于大數據傳輸的異構、多源、關聯等特點，即使多個數據集各自脫敏處理，數據集仍然存在因關聯分析而造成個人信息泄漏的風險。

安全配置管理主要包括以下內容：

• 資產管理：日常運維中需對硬件資源等資產進行管理。

• 資源管理：對信息資源進行管理，如服務器的啟動、停止、重啟等，虛擬機的創建、刪除、編輯，虛擬機的啟動、停止、重啟等操作。

• 服務目錄管理：將計算、網絡、存儲、應用軟件、系統模板等能力抽象為能夠提供的服務，并通過服務目錄管理模塊對這些服務進行管理。

• 服務請求，服務變更，工作流管理：包括對資源的申請、變更等工作流，還包括運維和管理過程中的工作流，對審核過程進行支持。

• 監控管理：對硬件資源、虛擬機、存儲、網絡安全等設備的運行狀態進行監控和報警。

確定定級對象安全保護等級的一般流程如下：

1. 確定受到破壞時所侵害的客體：確定業務信息受到破壞時所侵害的客體。確定系統服務安全受到破壞時所侵害的客體。

2. 確定對客體的侵害程度：根據不同的受侵害客體，分別評定業務信息安全被破壞對客體的侵害程度。根據不同的受侵害客體，分別評定系統服務安全被破壞對客體的侵害程度。

3. 確定安全保護等級：確定業務信息安全保護等級。確定系統服務安全保護等級。將業務信息安全保護等級和系統服務安全保護等級的較高者確定為定級對象的安全保護等級。

入侵檢測系統的工作原理如下：

• 數據收集：收集的數據包括主機日志、防火墻日志、數據庫日志、應用程序數據以及網絡數據包等；

• 數據處理：由于之前收集到的數據過于龐大和繁雜，需要對其進行相應的處理（去除冗余、噪聲，并且進行數據標準化及格式化處理）；

• 數據分析：采用統計、智能算法能方法分析數據是否正常，顯示是否存在入侵行為；

• 響應處理：當發現入侵行為時，采取預案措施進行防護（如切斷網絡，記錄日志）、并保留入侵證據以作他日調查所用，同時向管理員報警。

常見的響應代碼有：

• 1xx（信息提示）：表示請求已接收，繼續處理。

這些狀態代碼表示臨時的響應。客戶端在收到常規響應之前，應準備接收一個或多個1xx 響應。

- 100 - Continue 初始的請求已經接受，客戶應當繼續發送請求的其余部分。
- 101 - Switching Protocols 服務器將遵從客戶的請求轉換到另外一種協議。

• 2xx（成功）：表示成功處理了請求的狀態代碼。

這類狀態代碼表明服務器成功地接受了客戶端請求。

- 200 - OK 一切正常，對GET和POST請求的應答文檔跟在后面。

- 201 - Created 服務器已經創建了文檔，Location頭給出了它的URL。

- 202 - Accepted 已經接受請求，但處理尚未完成。

- 203 - Non-Authoritative Information 文檔已經正常地返回，但一些應答頭可能不正確，因為使用的是文檔的拷貝，非權威性信息。

- 204 - No Content 沒有新文檔，瀏覽器應該繼續顯示原來的文檔。如果用戶定期地刷新頁面，而Servlet可以確定用戶文檔足夠新，這個狀態代碼是很有用的。

- 205 - Reset Content 沒有新的內容，但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容。

- 206 - Partial Content 客戶發送了一個帶有Range頭的GET請求（分塊請求），服務器完成了它。

• 3xx（重定向）：表示要完成請求，需要進一步操作。 通常，這些狀態代碼用來重定向。

客戶端瀏覽器必須采取更多操作來實現請求。例如，瀏覽器可能不得不請求服務器上的不同的頁面，或通過代理服務器重復該請求。

 - 300 - Multiple Choices 客戶請求的文檔可以在多個位置找到，這些位置已經在返回的文檔內列出。如果服務器要提出優先選擇，則應該在Location應答頭指明。

 - 301 - Moved Permanently 客戶請求的文檔在其他地方，新的URL在Location頭中給出，瀏覽器應該自動地訪問新的URL。

 - 302 - Found 類似于301，但新的URL應該被視為臨時性的替代，而不是永久性的。注意，在HTTP1.0中對應的狀態信是“Moved Temporatily”。出現該狀態代碼時，瀏覽器能夠自動訪問新的URL，因此它是一個很有用的狀態代碼。注意這個狀態代碼有時候可以和301替換使 用。有的服務器返回301，有的則返回302。嚴格地說，我們只能假定只有當原來的請求是GET時瀏覽器才會自動重定向。請參見307。

  - 303 - See Other 類似于301/302，不同之處在于，如果原來的請求是POST，Location頭指定的重定向目標文檔應該通過GET提取。

   - 304 - Not Modified 客戶端有緩沖的文檔并發出了一個條件性的請求（一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔）。服務器告訴客戶，原來緩沖的文檔還可以繼續使用。

   - 305 - Use Proxy 客戶請求的文檔應該通過Location頭所指明的代理服務器提取（HTTP 1.1新）。

   - 307 - Temporary Redirect 和302（Found）相同。許多瀏覽器會錯誤地響應302應答進行重定向，即使原來的請求是POST，即使它實際上只能在POST請求的應答是303時 才能重定向。由于這個原因，HTTP 1.1新增了307，以便更加清除地區分幾個狀態代碼：當出現303應答時，瀏覽器可以跟隨重定向的GET和POST請求；如果是307應答，則瀏覽器只能跟隨對GET請求的重定向。

• 4xx（客戶端錯誤）：請求有語法錯誤或請求無法實現。

這些狀態代碼表示，請求可能出錯，已妨礙了服務器對請求的處理。

- 400 - Bad Request （錯誤請求） 服務器不理解請求的語法。

- 401 - Unauthorized （未授權） 請求要求進行身份驗證。登錄后，服務器可能會返回對頁面的此響應。

- 403 - Forbidden（已禁止） 服務器拒絕請求。通常由于服務器上文件或目錄的權限設置導致。

- 404 - Not Found（未找到） 服務器找不到請求的網頁。例如，如果請求是針對服務器上不存在的網頁進行的，那么，服務器通常會返回此代碼。

- 405 - Method Not Allowed 請求方法（GET、POST、HEAD、DELETE、PUT、TRACE等）對指定的資源不適用，用來訪問本頁面的 HTTP 謂詞不被允許。（方法不被允許）

- 406 - Not Acceptable 指定的資源已經找到，但它的MIME類型和客戶在Accpet頭中所指定的不兼容，客戶端瀏覽器不接受所請求頁面的 MIME 類型。

- 407 - Proxy Authentication Required （需要代理授權） 此狀態代碼與 401（未授權）類似，但卻指定了請求者應當使用代理進行授權。如果服務器返回此響應，那么，服務器還會指明請求者應當使用的代理。

- 408 - Request Timeout 在服務器許可的等待時間內，客戶一直沒有發出任何請求。客戶可以在以后重復同一請求。

- 409 - Conflict （沖突） 服務器在完成請求時發生沖突。服務器必須包含有關響應中所發生的沖突的信息。服務器在響應與前一個請求相沖突的 PUT 請求時可能會返回此代碼，同時會提供兩個請求的差異列表。

- 410 - Gone 所請求的文檔已經不再可用，而且服務器不知道應該重定向到哪一個地址。它和404的不同在于，返回407表示文檔永久地離開了指定的位置，而404表示由于未知的原因文檔不可用。

- 411 - Length Required （需要有效長度） 服務器不會接受包含無效內容長度標頭字段的請求，除非客戶發送一個Content-Length頭。

- 412 - Precondition Failed 請求頭中指定的一些前提條件失敗。

- 413 – Request Entity Too Large 目標文檔的大小超過服務器當前愿意處理的大小。如果服務器認為自己能夠稍后再處理該請求，則應該提供一個Retry-After頭。
- 414 - Request URI Too Long URI太長。

- 415 – 不支持的媒體類型。

- 416 – Requested Range Not Satisfiable 服務器不能滿足客戶在請求中指定的Range頭。

- 417 – 執行失敗。

- 423 – 鎖定的錯誤。

• 5xx（服務器端錯誤）：服務器未能實現合法的請求。

這些狀態代碼表示服務器在嘗試處理請求時發生內部錯誤。 這些錯誤可能是服務器本身的錯誤，而不是請求出錯。

- 500 - Internal Server Error（服務器內部錯誤） 服務器遇到錯誤，無法完成請求。

- 501 - Not Implemented（尚未實施） 服務器不具備完成請求的功能。例如，當服務器無法識別請求方法時，服務器可能會返回此代碼。

- 502 - Bad Gateway（錯誤網關） 服務器作為網關或代理，從上游服務器收到了無效的響應。

- 503 - Service Unavailable （服務不可用） 目前無法使用服務器（由于超載或進行停機維護）。通常，這只是一種暫時的狀態。

- 503 - Service Unavailable （服務不可用） 目前無法使用服務器（由于超載或進行停機維護）。通常，這只是一種暫時的狀態。

- 504 - Gateway Timeout （網關超時） 服務器作為網關或代理，未及時從上游服務器接收請求。

- 505 - HTTP Version Not Supported （HTTP 版本不受支持） 服務器不支持請求中所使用的 HTTP 協議版本。

• 修改DBA登錄密碼在shell環境下執行

mysqladmin -u root password

• 連續輸入兩次新密碼非首次修改

mysqladmin -u root password -p原密碼

• 連續輸入兩次新密碼在mysql下執行t-sql語句

update user set password=password(‘密碼') where user='root'; 
flush privileges; 

• 刪除測試庫

show databases;
drop?database?test; 

• 刪除非root用戶

use mysql; 
 delete from user where not (user='root') ; 

• 刪除密碼為空的root用戶

delete from user where user='root' and password=’’;
flush privileges; 

• 變更DBA用戶名

use mysql;
update user set user=”nicai " where user="root"; 
flush privileges; 

• 在賬戶管理時使用加密算法

use mysql;
insert into users values (1,password(123.com),'test'); 

• 更改mysql啟動用戶修改my.cnf文件

vim /etc/my.cnf
加入如下內容
[mysqld]
user=mysql

• 限制遠程連接數

修改my.cnf文件，去掉注釋符號vi  /etc/my.cnf加入如下內容
[mysqld]
max_connections = 5
max_user_connections=2
或者限制某個用戶，在mysql中執行
GRANT test  ON *.* TO testdb@localhost MAX_USER_CONNECTIONS 2;

• 關閉遠程管理數據庫

修改my.cnf文件，去掉注釋符號
vi  /etc/my.cnf
修改如下內容
#skip-networking
           ↓
skip-networking

• 清理mysql命令歷史

注意清理家目錄中的.mysql_history
ln -s /dev/null  /root/.mysql_history
禁止使用明文模式登陸mysql
mysql  -u root -p123.com
應使用隱藏密碼方式
mysql  -u root -p

• 禁止將表導出到文件

在mysql中修改用戶的文件權限
update user set File_priv=‘N’ where user=‘用戶名'; 
檢查配置文件是否存在不合理信息
grep  secure_file_priv  /etc/my.cnf
secure_file_priv= xxx路徑
*********導出的測試命令************
select * from mysql.user into outfile 'test1.txt' fields terminated by ',';

• 日常備份數據庫

mysqldump --user=root --all-databases --flush-privileges --lock-all-tables  --master-data=1 --flush-logs --triggers --routines --events  --hex-blob > 備份路徑/文件名時間戳.sql

IDS與防火墻聯動的部署方案存在如下不足：

• 使用、設置上復雜，影響防火墻的穩定性與性能。

• 阻斷來自源地址的流量，不能阻斷連接或單個數據包。

• 黑客盜用合法地址發起攻擊，造成防火墻拒絕來自該地址的合法訪問。

• 可靠性差，實際環境中沒有實用價值。

因為諸多不足，在目前而言，IDS主要起的還是監聽記錄的作用。用個比喻來形容：網絡就好比一片黑暗，到處充滿著危險，冥冥中只有一個出口。IDS就像一支手電筒，雖然手電筒不一定能照到正確的出口，但至少有總比沒有要好一些。稱職的網管，可以從IDS中得到一些關于網絡使用者的來源和訪問方式，進而依據自己的經驗進行主觀判斷對IDS的選擇，跟上面談到的防火墻的選擇類似，根據自己的實際要求和使用習慣，選擇一個自己夠用的，會使用的就足夠了。

云原生安全有以下這些特性：

• 輕快不變的基礎設施：云原生環境中支撐基礎設施的通常是容器技術，而容器技術占用資源小，生命周期短以秒或者分鐘為基本單位。云原生在實際實踐中不會在容器中安裝或者更新應用，而是更新為更持久化的鏡像。這種更新鏡像而不改變容器運行模式稱為不變的基礎設施。

• 彈性服務編排：云原生的焦點是業務，業務的核心之處是業務管理和控制。服務編排提供了強大的業務支撐能力，可以彈性的控制服務的位置、容量、版本、監控保證業務的可訪問性。

• 開發運營一體化：通過講軟件開發和運營相互結合，縮短軟件開發周期，開發理念包括自動化構建、測試、持續集成和持續交付等等。

• 微服務架構：將傳統的單體應用的功能拆解成大量單獨、細粒度的服務。通過應用編排組裝、實現等價于傳統單體應用的復雜功能。

• 無服務模型：無服務是一種基于代碼和計算任務執行的云計算抽象模型，與之相對的是基于服務器的計算模式。無服務聚焦在函數計算，隱藏了底層復雜的實現方，使開發者能夠聚焦業務本身。

區塊鏈的特征如下：

• 去中心化：由于使用分布式核算和存儲，區塊鏈體系不存在中心化的硬件或管理機構，因此任意節點的權利和義務都是均等的，系統中的數據塊由整個系統中具有維護功能的節點來共同維護。

• 開放性：系統是開放的，除交易各方的私有信息被加密之外，區塊鏈的數據對所有人公開，任何人都可以通過公開的接口查詢區塊鏈數據和開發相關應用，因此整個系統信息高度透明。

• 自治性：區塊鏈采用基于協商一致的規范和協議（如一套公開透明的算法）使得整個系統中的所有節點能夠在去信任的環境中自由安全的交換數據，使得對“人”的信任換成了對機器的信任，任何人為的干預都不起作用。

• 信息不可篡改：一旦信息經過驗證并添加至區塊鏈，就會永久的存儲起來，除非能夠同時控制系統中超過51%的節點，否則單個節點上對數據庫的修改是無效的，因此區塊鏈的數據穩定性和可靠性極高。

• 匿名性：由于節點之間的交換遵循固定的算法，其數據交互是無須信任的（區塊鏈中的程序規則會自行判斷活動是否有效），因此交易對手無須通過公開身份的方式讓對方對自己產生信任，對信用的累積非常有幫助。

• 可靠性：區塊鏈上的數據保存多個副本，任何節點的故障都不會影響數據的可靠性。共識機制使得修改大量區塊的成本極高，幾乎是不可能的。破壞數據并不符合重要參與者的自身利益，這種實用設計增強了區塊鏈上的數據可靠性

• 全球流通: 區塊鏈資產首先是基于互聯網的，只要有互聯網的地方，區塊鏈資產就可以進行流通。這里的互聯網可以是萬維網，也可以使各種局域網，所以區塊鏈資產是全球流通的。只要有互聯網，就可以把區塊鏈資產轉賬，相較于中心化的方式，區塊鏈資產在全球流通的轉賬手續費非常低，比如比特幣早期轉賬手續費為0.0001BTC，相對于傳統轉賬來說，區塊鏈資產到賬也非常快。一般幾分鐘到1小時就能到賬。