對于大多數企業而言，資訊化建設的主要目的是通過資訊化驅動業務，實作業務更新與優化，主要有三種展現形式：建設業務系統，實作業務流程标準化、便捷化；整合業務系統和資料，形成資料資産；業務資料呈現，直覺展現業務的變化和發展。無論哪種方式，資料都是資訊化建設的重中之重，是以企業在進行資訊化建設時，尤其要考慮安全性問題，并且要從硬體、軟體、網絡等多個層面進行防護。
對于資訊化平台而言，除了要考慮平台本身的通路安全、使用安全外，對于資料傳輸的安全也是非常重要的，特别是內建類項目或者跨網絡資料傳輸的情況。最近在傳遞一個內建底座（IDM+MDM+ESB）的項目時，對IDM平台進行了安全優化，由于IDM平台主要是統一認證，是以主要對短信重置密碼的功能進行了安全優化處理。
1總體說明
內建底座項目主要包括三款産品，分别是IDM統一身份管理平台、MDM基礎資料管理平台和ESB應用內建平台，主要作用是幫助企業建立基礎的資訊化架構，打通業務系統的壁壘，通過IDM完成5A管控（統一使用者、統一認證、統一授權、統一審計、統一應用管控），通過MDM完成基礎資料治理，通過ESB實作API治理以及應用系統的業務內建等。
1.1.內建架構
內建底座的內建方案，基于IDM、MDM、ESB實作業務系統的對接，完成系統內建、統一認證的同時，也支撐企業的基礎資料治理和業務內建的需求的實作。內建底座包括了三個産品，通過産品的組合也包括了三個子方案：MDM + ESB主資料治理方案、IDM + ESB統一5A管控方案、ESB + MDM統一內建平台方案，整體架構圖如下圖所示：
1.MDM + ESB主資料治理方案：以MDM産品為核心進行主資料治理，由HR、ERP、财務等源頭系統提供基礎資料，經由ESB同步至MDM中進行管理、清洗、校驗等，并通過MDM平台推送至下遊系統，進而完成整個基礎資料治理工作，治理範圍可以包括企業内部所有的基礎資料，如組織、崗位、人員、客戶、供應商、物料、合同會計科目、銀行賬号等；
2.IDM + ESB統一5A管控方案：以IDM産品為核心完成5A管控，完成各個系統的統一使用者、統一認證、統一權限等，由于通過MDM完成了基礎資料治理，可以直接由MDM提供組織、人員資料到IDM形成賬号資料，再下發至各個系統中，統一下遊系統完成基于IDM平台的統一認證接入和權限接入等；
3.ESB + MDM統一內建平台方案：以ESB平台為主的業務內建方案，将業務系統的相關服務和API注冊到ESB平台進行統一管理，根據實際業務需求，将源頭系統的業務單據通過ESB的應用內建進行映射轉換處理，再推送到下遊系統中，實作跨系統業務對接，同時結合MDM的主資料治理，保證了業務資料關聯的有效性和準确性。
1.2部署架構
內建底座方案目前主要采用雲平台的部署方案，實作産品的容器化部署，通過k8s進行容器管理，基于UMC雲管理平台實作基于Web端的快速部署配置，包括伺服器的注冊、k8s的部署、産品的部署、更新、伺服器監控、擴容等都可以通過UMC完成。
雲平台叢集部署至少需要5台伺服器保證高可用，同時根據需要也可以添加更多的節點保證性能，如圖是采用了8台伺服器的部署方案，其中3個master節點，5個worker節點，IDM、ESB、MDM采用容器化部署在5個worker節點上，worker1、worker2用于部署開發、測試環境，兩台伺服器各一個節點，worker3、worker4、worker5用于部署3個節點的生産環境。
1.3需求說明
由于IDM作用統一身份認證平台，在內建業務系統後主要起到統一認證入口的作用，使用者、密碼資訊都儲存在IDM平台中，是以在IDM平台添加了很多安全限制，如密碼安全政策、登入政策等來強化登入管理，同時為了便于最終使用者的使用，添加了短信重置密碼的功能，但由于短信重置需要和短信平台互動，同時涉及到了使用者的手機号等敏感資訊，是以對于發送短信的功能要添加必要的安全限制，進而保證平台使用的安全性。
2需求分析
基于IDM短信重置密碼功能的安全需求，綜合考慮産品和部署架構體系，結合改功能的使用方式，決定從網絡和平台兩個層面進行優化，網絡層面主要考慮對IP進行控制，保證通路IP的安全性，平台主要是從IDM、ESB平台功能和短信平台方面進行優化。
2.1功能說明
針對IDM平台的短信重置密碼功能，首先該功能不是由IDM平台獨立安城的，需要IDM集合ESB平台共同完成，由于短信平台一般都是外部的專用平台，并且不同平台的API也各不相同，是以IDM的短信發送是通過調用ESB的接口，而ESB通過開發對應的短信發送接口進而實作整個功能。
2.2網絡優化
根據內建底座的部署架構，短信重置密碼需要基于浏覽器操作，而浏覽器通路是通過Nginx代理的方式進入的，是以首先考慮在Nginx上添加高頻IP限流，防止同一IP反複發送請求，進而導緻平台的使用收到威脅。
2.3 平台優化
平台優化主要包括兩個方面，一是從IDM和ESB平台進行優化，由于密碼重置功能是通過IDM平台進行操作的，首先在IDM平台即用戶端添加短信發送的間隔控制，保證不能連續的點選發送短信功能；二是在ESB流程控制，調用ESB流程發送短信時，進行發送的控制，即服務端控制，實作雙重控制保證安全。二是在短信平台控制，即控制短信平台發送次數，針對同一賬号進行發送限制，但由于該限制需要外部短信平台實作，同時可能會關聯影響到客戶業務操作的短信提醒，是以不做過多說明。
3優化政策
根據具體需求以及針對需要的分析結果，考慮從伺服器網絡、産品和短信平台三個層面進行優化，而伺服器網絡和短信平台均屬于外部環境，需要客戶方或第三方完成，是以不做過大說明，主要針對IDM和ESB平台的相關功能進行說明。
3.1IP位址限制
該限制主要限制進行密碼重置操作的IP位址，如果在固定時間内，同一IP多次進行密碼重置擦操作，無論是否是針對同一賬号發起的密碼重置，都會對該IP進行鎖定，限制該IP在一段時間内無法再進行密碼重置操作。考慮到實際業務的需求，相關參數采用配置的方式：
1.IP限制的時間範圍，以秒為機關；
2.發送短信重置密碼的次數；
3.IP鎖定的時間，以分鐘為機關；
4.考慮到内網發起以及無操作的情況，增加了IP白名單，加入白名單的将不再進行IP限制。
3.2時間間隔
延長用戶端進行密碼重置操作的時間間隔，即每次進行發送短信操作後，需要間隔一段時間後才能再次進行短信發送操作。
1.發送的時間間隔可以配置；
2.該限制為用戶端限制，如果用戶端進行重新整理或重置，會導緻限制消失，是以需要和服務端限制配合。
3.3賬号驗證
賬号驗證即用戶端時間間隔限制的服務端處理，即在ESB接口的服務端，也會進行發送時間間隔的限制，每次發送後需要間隔一段時間才能再次進行發送操作。
1.發送的時間間隔可以配置，和用戶端的時間間隔是同一參數；
2.服務端限制是限制相同賬号，不同賬号不受時間間隔限制，但如果采用兩個賬号交替發送也會受到限制；
3.服務端限制不限用戶端類型，不論是PC端還是移動端都受到限制，并且該限制是共享的。
3.4賬号限制
增加發送保護政策，和IP限制類似，但是是限制的登入賬号，即同一賬号一定時間内發送次數過多，則鎖定一段時間後才能發送。相關的配置參數和IP位址限制的參數類似：
1.賬号限制的時間範圍，以秒為機關；
2.發送短信重置密碼的次數；
3.賬号鎖定的時間，以分鐘為機關；
4.賬号限制沒有白名單的配置，即賬号一旦鎖定，則無法解鎖，隻能等到鎖定時間結束。
4接口流程
發送短信重置密碼的優化包括IDM和ESB流程兩部分，但IDM部分主要由用戶端限制，即在操作頁面增加操作限制，相對簡單不做重點說明，主要針對ESB流程進行重點介紹。由于短信發送調用的是一個ESB接口，為了保證流程開發維護的友善，以及業務的區分，分成了三部分，分别是IP位址限制、賬号限制和發送間隔，建立三個接口，通過ESB的接口調用實作整體連接配接。
1.IP位址限制：主流程入口，發送短信的第一次驗證，主要校驗IP的合法性，包括IP白名單和IP鎖定；
2.賬号限制：賬号服務接口，主要校驗賬号的合法性，即賬号是否被鎖定；
3.發送間隔：短信發送服務接口，主要校驗同一賬号是否滿足發送時間間隔的限制，以及調用短信平台API發送短信。
4.1參數配置
由于發送短信的主要流程是ESB流程，并且服務端的相關校驗也是通過ESB實作的，是以檢驗的相關參數直接在ESB的SMC中進行配置，如圖全局變量參數如下：
而在接口開發的過程中，相關IP、賬号、時間的判斷是通過Redis實作的，即将相關的調用資訊存儲在Redis中，而存儲短信發送資訊對Redis消耗并不大，是以直接使用ESB的Redis叢集進行存儲，在SMC配置ESB的Redis叢集資訊：
4.2IP位址限制
IP位址限制的ESB流程圖如下：
1.短信發送流程校驗的第一步，先校驗用戶端IP是否合法；
2.在ESB全局變量中加一個短信發送IP白名單配置，如果IP在白名單中，則不進行IP校驗，直接進入賬号校驗流程，否則進行IP校驗，進行下面步驟；
3.由于IDM的短信發送功能做了調整，通過平台調用時可以在請求頭中記錄請求用戶端的IP；
4.ESB流程中通過Redis進行IP的判斷，Redis存儲的key為接收到的IP，Redis存儲的資料格式為：<ip>ip位址</ip><startTime>開始時間</startTime><invokeNum>調用次數</invokeNum><isLock>是否鎖定</isLock>；
5.根據header中的IP從Redis中擷取存儲的資訊（DataRow），根據鎖定狀态、調用次數、（目前-開始）時間差進行判斷：
1)賬号已鎖定 && 時間差 <= IP鎖定時間（全局變量配置）：直接提示“IP已被鎖定，請xx分鐘後重試”；
2)賬号已鎖定 && 時間差 > IP鎖定時間（全局變量配置）：DataRow狀态改為解鎖，次數 = 1，開始時間 = 目前時間，更新Redis資料，調用下一步（賬号判斷）操作；
3)未鎖定 && 次數 >= IP發送次數（全局變量配置） && 時間差 <= IP時間範圍（全局變量配置）：DataRow狀态改為鎖定，更新Redis資料，提示“IP已被鎖定，請xx分鐘後重試”；
4)未鎖定 && 次數 < IP發送次數（全局變量配置） && 時間差 <= IP時間範圍（全局變量配置）：次數+1，更新Redis資料，調用下一步（賬号判斷）操作；
5)未鎖定 && 時間差 > IP時間範圍（全局變量配置）：次數 = 1，更新Redis資料，調用下一步（賬号判斷）操作。
4.3賬号限制
賬号限制的ESB流程圖如下：
1.和IP校驗方式類似，隻是Redis存儲的資訊不同；
2.ESB流程中通過Redis進行手機号的判斷，Redis存儲的key為接收到的手機号，Redis存儲的資料格式為：<tel>手機号</tel><startTime>開始時間</startTime><lastOperTime>最後發送時間</lastOperTime><invokeNum>調用次數</invokeNum><isLock>是否鎖定</isLock>；
3.根據手機号從Redis中擷取存儲的資訊（DataRow），根據鎖定狀态、調用次數、（目前-開始）時間差進行判斷：
1)賬号已鎖定 && 時間差 <= 賬号鎖定時間（全局變量配置）：直接提示“賬号已被鎖定，請xx分鐘後重試”；
2)賬号已鎖定 && 時間差 > 賬号鎖定時間（全局變量配置）：DataRow狀态改為解鎖，次數 = 1，開始時間 = 目前時間，更新Redis資料，調用下一步（賬号判斷）操作；
3)賬号未鎖定 && 次數 >= 賬号發送次數（全局變量配置） && 時間差 <= 賬号時間範圍（全局變量配置）：DataRow狀态改為鎖定，更新Redis資料，提示“賬号已被鎖定，請xx分鐘後重試”；
4)賬号未鎖定 && 次數 < 賬号發送次數（全局變量配置） && 時間差 <= 賬号時間範圍（全局變量配置）：次數+1，更新Redis資料，調用下一步（短信發送判斷）操作；
5)賬号未鎖定 && 時間差 > 賬号時間範圍（全局變量配置）：DataRow次數 = 1，開始時間 = 目前時間，更新Redis資料，調用下一步（短信發送判斷）操作。
4.4發送間隔
短信發送間隔的流程和ESB調用短信平台的接口是在同一個流程中，也是整個短信發送流程的最後一個環節，流程圖如下：
1.ESB流程中通過Redis進行手機号的判斷，Redis複用賬号校驗流程的Redis；
2.根據手機号從Redis中擷取存儲的資訊（DataRow），根據（目前-最後發送時間）時間差進行判斷：
1)時間差 <= 發送時間間隔（全局變量配置），直接提示“短信發送時間小于xxx秒，請xxx秒後重試”；
2)時間差 > 發送時間間隔（全局變量配置），發送短信，提示“發送成功”。
5測試說明
短信流程的測試也是以滿足實際需求為前提，根據開發的相關流程和業務場景進行測試，主要包括針對IP位址限制、賬号限制、發送間隔三個層面，主要測試場景如下：
1.相同IP，輸入不同賬号進行發送測試，測試在1分鐘内連續發送後IP是否提示鎖定；
2.IP鎖定後将IP加入白名單，測試該IP是否可以繼續發送；
3.取消IP白名單，再次發送測試是否會繼續鎖定；
4.同一賬号，在不同IP下進行短信發送，測試每次發送後是否需要等待2min才能再次發送；
5.同一賬号，在不同IP下進行短信發送，10分鐘内連續發送4次，測試賬号是否會被鎖定；
6.30min之後再次嘗試發送，确認賬号是否已經解鎖。
5.1IP位址測試
1.相同IP，不同賬号：
2.IP白名單：
3.取消白名單：
5.測試通過。
5.2賬号限制測試
1.相同賬号，不同IP（PC端和手機APP）：
2.鎖定結束：
3.測試通過。
5.3發送間隔測試
主要測試用戶端和服務端進行短信發送時，是否存儲2min的時間限制。
1.用戶端發送測試：
2.服務端限制：
3.測試通過，并且能保證PC端和移動端的間隔時間共享。
6總結說明
IDM統一身份管理平台作為5A安全管控平台，本身就提供了大量的安全管控措施，包括密碼安全政策、登入安全政策等，本次也是在原有的密碼重置功能上進行了一次安全層面的優化。
6.1産品功能
IDM産品本身從安全和使用的角度考慮，已經預置了短信的功能，但是由于短信平台一般都是采用第三方，是以導緻不同項目中短信平台API都不相同，是以難以統一放到IDM中，是以一直都是通過ESB流程進行開發，本次優化也是采用這種方式。但是由于本次優化增加了IP、賬号等一系列限制，導緻ESB的流程相對複雜，後續可以考慮在IDM平台通過添加安全政策的方式進行配置，ESB流程隻負責進行短信發送，這樣可以使産品功能更加完善，同時項目實施的難度也會大幅度降低。