偵測行動銀行詐騙

在典型的在線欺詐案例中，小偷進行多筆交易，導致數千美元損失。 這就是為什麼詐騙偵測必須近乎實時地進行。 超過8億人使用行動應用程式。 隨著這個數位的增加，移動銀行欺詐也有所增加。 金融業正經歷著100%的同比增長，因為從移動平台獲得而造成的損失。 但有一種緩和措施。 本文提供解決方案，其使用 Azure 技術在兩秒內預測詐騙行動銀行交易。 此處呈現的架構是以真實世界解決方案為基礎。

挑戰：欺詐和嚴格規則的罕見實例

大部分的行動詐騙發生在使用 SIM 交換攻擊來危害行動電話號碼時。 複製電話號碼，罪犯會收到傳送給受害者行動裝置的簡訊通知和電話。 然後，罪犯會使用社交工程、網路釣魚、使用手機進行網路釣魚或受感染的下載應用程式來取得登入認證。 利用這些資訊，罪犯可以冒充銀行客戶，註冊移動訪問，並立即產生資金轉移和取款。

對於消費者和銀行來說，移動詐騙很難發現和昂貴。 第一個挑戰是，這是罕見的。 所有交易中只有不到 1% 是詐騙的，因此詐騙或案例管理團隊可能需要時間篩選潛在的詐騙交易，以識別詐騙交易。 第二個挑戰是許多詐騙監視解決方案依賴以規則為基礎的引擎。 傳統上，以規則為基礎的引擎可在偵測從具風險的IP位址或新帳戶上短暫期間內產生的多個交易所產生的類似詐騙交易的已建立模式時有效。 但以規則為基礎的引擎有顯著的限制：規則不會快速適應新的或不斷演變的攻擊類型。 它們受限於下列方式：

• 偵測不是即時的，因此會在發生財務損失之後偵測到詐騙。
• 規則為二進位和有限。 它們無法容納可評估之輸入變數的複雜度和組合。 這項限制會導致大量誤判。
• 規則會硬式編碼為商業規則。 策劃規則、併入新的數據源，或新增詐騙模式通常需要影響商務程式的應用程序變更。 在整個商務程式中傳播變更可能會很麻煩且昂貴。

AI 模型可以大幅改善詐騙偵測率和偵測時間。 銀行正將這些模型與其他方法來減少損失。 這裡所述的程式是以三個元素為基礎：

• 在衍生的行為特性集上運作的 AI 模型
• 機器學習方法
• 模型評估程式，類似於詐騙經理用來評估組合的模型評估程式

操作內容

對於此解決方案所依據的銀行而言，隨著客戶增加數位服務的使用，整個行動管道的詐騙激增。 現在是該銀行重新考慮其欺詐檢測和預防方法的時候了。 此解決方案從影響其詐騙程式和決策的問題開始：

• 哪些活動或交易可能會詐騙？
• 哪些帳戶遭到入侵？
• 哪些活動需要進一步調查和案例管理？

若要讓解決方案實現價值，必須清楚瞭解移動銀行詐騙在操作環境中如何明顯：

• 平臺上會永久存在哪些類型的詐騙？
• 如何認可？
• 詐騙活動和交易中的模式為何？

這些問題的解答導致瞭解可發出詐騙之行為類型。 數據屬性已對應至從行動應用程式閘道收集的訊息，這些訊息與所識別的行為相互關聯。 接著會分析與判斷詐騙最相關的帳戶行為。

下表識別可能發出詐騙訊號的數據屬性，以及與銀行相關的行為類型：

* 最常見的入侵指標。 它之前是金融和非金融妥協。

行為維度對於偵測行動詐騙至關重要。 行為型配置檔可協助建立帳戶的典型行為模式。 分析可以指出看似超出規範的活動。 以下是可分析的一些行為類型範例：

• 有多少帳戶與裝置相關聯？
• 有多少裝置與帳戶相關聯？ 他們卸除或新增的頻率？
• 裝置或客戶登入的頻率為何？
• 客戶變更密碼的頻率為何？
• 帳戶的平均貨幣轉移或取款金額為何？
• 從帳戶中取款的頻率是多少？

解決方案會根據下列方式使用方法：

• 為客戶和帳戶建立行為配置檔的功能工程。
• Azure 機器學習服務可針對可疑或不一致的帳戶行為建立詐騙分類模型。
• 適用於即時事件處理和端對端工作流程的 Azure 服務。

高階結構

下載此架構的 Visio 檔案。

資料流程

此架構中有三個工作流程：

• 事件驅動管線會擷取及處理記錄數據、建立和維護行為帳戶配置檔、併入詐騙分類模型，併產生預測分數。 此管線中的大部分步驟都是從 Azure 函式開始。 Azure 函式會使用，因為它們是無伺服器、易於相應放大和排程的。 此工作負載需要處理數百萬個傳入的行動交易，並近乎即時地評估其詐騙。

• 模型定型工作流程結合了內部部署歷程記錄詐騙數據和內嵌的記錄數據。 此工作負載是批次導向，用於模型定型和重新定型。 Azure Data Factory 會協調處理步驟，包括：

  • 從內部部署來源上傳已標記的歷史詐騙數據。
  • 封存所有交易的數據集和計分歷程記錄。
  • 將事件和訊息擷取成結構化格式，以進行特徵工程和模型重新定型和評估。
  • 透過 Azure 機器學習 訓練和重新定型詐騙模型。

• 第三個工作流程會與後端商務程式整合。 您可以使用 Azure Logic Apps 來連線並同步至內部部署系統，以建立詐騙管理案例、暫停帳戶存取，或產生電話聯繫人。

此架構的核心是數據管線和 AI 模型，本文稍後會更詳細地討論。

此解決方案會使用企業服務總線 （ESB） 和高效能的網路連線，與銀行的內部部署環境整合。

數據管線和自動化

當罪犯可以透過行動應用程式存取銀行帳戶時，財務損失可能在幾分鐘內發生。 在犯罪分子與行動應用程式互動時，以及在發生貨幣交易之前，必須有效偵測詐騙活動。 對詐騙交易做出反應所需的時間直接影響到可避免多少財務損失。 偵測越早，財政損失就越少。

不到兩秒，最好少得多，是移動銀行活動轉寄處理需要評估詐騙的最大時間量。 這是在這兩秒內需要發生的事情：

• 收集複雜的 JSON 事件。
• 驗證、驗證、剖析和轉換 JSON。
• 從數據屬性建立帳戶功能。
• 提交交易以進行推斷。
• 擷取詐騙分數。
• 與後端案例管理系統同步。

在詐騙偵測解決方案中，延遲和回應時間非常重要。 支援它的基礎結構必須快速且可調整。

事件處理

來自銀行行動和因特網應用程式閘道的遙測事件會格式化為具有鬆散定義架構的 JSON 檔案。 這些事件會以應用程式遙測的形式串流至 Azure 事件中樞，其中專用 App Service 環境 中的 Azure 函式會協調處理。

下圖說明此基礎結構內 Azure 函式的基本互動：

下載此架構的 Visio 檔案。

資料流程

1. 從事件中樞擷取原始 JSON 事件承載，並使用從 Azure 金鑰保存庫 擷取的 SSL 憑證進行驗證。
2. 協調 Azure Data Lake 中原始 JSON 訊息的還原串行化、剖析、儲存和記錄，以及 Azure SQL 資料庫 中的用戶財務交易歷程記錄。
3. 從 SQL 資料庫和 Data Lake 更新和擷取使用者帳戶和裝置配置檔。
4. 呼叫 Azure 機器學習 端點以執行預測模型並取得詐騙分數。 將推斷結果保存到數據湖以進行作業分析。
5. 透過 Azure Synapse Analytics 將 Power BI 連線 至 Data Lake，以取得實時作業分析儀錶板。
6. 將評分結果張貼為內部部署系統的事件，以進行進一步的詐騙調查和管理活動。

數據前置處理和 JSON 轉換

在此解決方案所依據的實際案例中，預先處理數據是格式化機器學習模型開發和定型數據不可或缺的一步。 有多年的歷史移動和因特網銀行事件，包括來自應用程式閘道遙測的事務數據，格式為 JSON。 有數十萬個檔案包含多個事件，這些事件需要還原串行化和扁平化並加以清除，以定型機器學習模型。

每個應用程式閘道都會從使用者的互動產生遙測數據，擷取OS、行動裝置元數據、帳戶數據，以及交易要求和回應等資訊。 JSON 檔案和屬性之間有差異，數據類型不同且不一致。 JSON 檔案的另一個複雜情況是，屬性和數據類型可能會意外變更，因為應用程式更新已推送至閘道，並移除、修改或新增功能。 架構的數據轉換挑戰包括下列各項：

• JSON 檔案可能包含一或多個行動電話互動。 每個互動都必須擷取為個別訊息。
• 欄位可能以不同的方式命名或表示。
• 新行或歸位字元等字元會內嵌在訊息中不一致。
• 電子郵件地址等屬性可能遺失或部分格式化。
• 可能有複雜的巢狀屬性和值。

Spark 集區是冷路徑的一部分，用來處理歷程記錄 JSON 檔案，以及還原串行化、扁平化和擷取裝置和交易屬性。 每個 JSON 檔案都會經過驗證和剖析，而且交易屬性會擷取並保存至數據湖，並根據交易日期進行分割。

這些屬性稍後會用來建立詐騙分類器的功能。 此解決方案的強大功能仰賴 JSON 數據能夠標準化、聯結及匯總歷程記錄數據，以建立行為配置檔。

使用 SQL 資料庫 進行近乎實時的數據處理和特徵化

在此解決方案中，事件會從多個來源產生，包括驗證記錄、客戶資訊和人口統計、事務歷史記錄，以及來自行動裝置的記錄和活動數據。 SQL 資料庫 可用來執行實時數據剖析、前置處理和特徵化，因為許多開發人員都熟悉 SQL。

HTAP 功能是擷取特定裝置在過去七天內的用戶帳戶行為歷程記錄，以近乎即時的方式計算低延遲的功能。 在 SQL 資料庫 中，會使用這些混合式交易/分析處理 （HTAP） 功能：

• 記憶體優化數據表 會儲存帳戶配置檔。 記憶體優化數據表比傳統 SQL 數據表具有優勢，因為它們是在主要記憶體中建立和存取。 避免磁碟存取的延遲和額外負荷。 此解決方案的需求是處理 300 個 JSON 訊息/秒。 記憶體優化數據表提供此層級的輸送量。
• 記憶體優化數據表最有效率地從 原生編譯的預存程式存取。 不同於解譯的預存程式，原生編譯預存程式會在第一次建立時進行編譯。
• 時態表是自動維護變更歷程記錄的數據表。 加入或更新數據列時，會建立版本並寫入記錄數據表。 在此解決方案中，帳戶配置檔會儲存在具有7天保留原則的時態表中，因此數據列會在保留期間之後自動移除。

此方法也提供下列優點：

• 存取封存的數據以進行作業分析、機器學習模型重新定型和詐騙驗證
• 簡化數據封存至長期記憶體
• 透過分區化數據和彈性資料庫的使用來延展性

事件架構管理

架構管理的自動化是此解決方案需要解決的另一項挑戰。 JSON 是彈性且可攜式的檔格式，部分原因是架構不會與數據一起儲存。 當 JSON 檔案需要剖析、還原串行化及處理時，表示 JSON 結構的架構必須編碼在某處，才能驗證數據屬性和數據類型。 如果架構未與傳入 JSON 訊息同步處理，JSON 驗證會失敗，而且不會擷取數據。

當 JSON 訊息的結構因為新的應用程式功能而變更時，就會面臨挑戰。 在其原始解決方案中，建立此解決方案的銀行會部署多個應用程式網關，每個閘道都有自己的UI、功能、遙測和JSON訊息結構。 當架構與傳入 JSON 數據同步時，不一致會導致數據遺失，並處理詐騙偵測的延遲。

銀行並未針對這些事件定義正式架構，而且在解決方案的每個反覆專案上建立技術債務的 JSON 檔案結構持續波動。 此解決方案可藉由建立這些事件的架構並使用 Azure 架構登錄來解決該問題。 Azure 架構登錄 提供事件架構的中央存放庫，讓生產者和取用者應用程式可以交換數據，而不需要管理及共享架構。 它為可重複使用的架構所引進的簡單治理架構，以及透過群組建構（架構群組）在架構之間定義的關聯性，可以消除重大技術債務、強制執行一致性，以及跨變更架構提供回溯相容性。

機器學習功能工程

功能 可讓您透過匯總不同時間規模的活動來分析帳戶行為。 它們是從代表交易式、非交易式和裝置行為的應用程式記錄中的數據建立的。 交易行為包括貨幣交易活動，例如付款和取款。 非交易行為包括用戶動作，例如登入嘗試和密碼變更。 裝置行為包括涉及行動裝置的活動，例如新增或移除裝置。 功能可用來代表目前和過去的帳戶行為，包括：

• 來自特定裝置的新用戶註冊嘗試。
• 成功和失敗的登入嘗試。
• 新增第三方付款人或受益人的要求。
• 增加帳戶或信用卡限制的要求。
• 密碼變更。

帳戶配置文件數據表包含來自 JSON 交易的屬性，例如訊息標識碼、交易類型、付款金額、一周中的一天和一小時。 活動會跨多個時間範圍匯總，例如一小時、一天和七天，並儲存為每個帳戶的行為歷程記錄。 數據表中的每個數據列都代表單一帳戶。 以下是一些功能：

計算帳戶功能並更新配置文件之後，Azure 函式會呼叫機器學習模型，以透過 REST API 進行評分以回答此問題： 根據我們所看到的行為，此帳戶處於詐騙狀態的可能性為何？

AutoML

AutoML 用於解決方案中，因為它快速且容易使用。 AutoML 可以是快速探索和學習的實用起點，因為它不需要特殊知識或設定。 它會自動化機器學習模型開發的耗時反覆工作。 數據科學家、分析師和開發人員可以使用它來建置具有高延展性、效率和生產力的機器學習模型，同時維持模型品質。

AutoML 可以在機器學習程序中執行下列工作：

• 將數據分割成定型和驗證數據集
• 根據所選計量優化定型
• 執行交叉驗證
• 產生功能
• 插補遺漏的值
• 執行單熱編碼和各種縮放程式

數據不平衡

詐騙分類是具有挑戰性的，因為嚴重的類別不平衡。 在詐騙數據集中，比詐騙交易更多的非詐騙交易。 一般而言，少於 1% 的數據集包含詐騙交易。 如果未解決，此不平衡可能會導致模型中的信譽問題，因為所有交易最終都分類為非詐騙。 模型可能會完全遺漏所有詐騙交易，但仍達到 99% 的準確率。

AutoML 可協助重新發佈數據，並在詐騙和非詐騙交易之間建立更好的平衡：

• AutoML 支援新增加權數據行做為輸入，導致數據中的數據列增加或減少加權，這會使類別變得不那麼重要。 當少數類別中的樣本數目等於或小於多數類別樣本數目的 20% 時，AutoML 所使用的演算法會偵測到不平衡。 接著，AutoML 會使用子取樣數據執行實驗，以檢查使用類別權數是否可解決此問題並改善效能。 如果它判斷效能較佳，因為實驗，則會套用補救。
• 您可以使用效能測量計量，以更妥善處理不平衡的數據。 例如，如果您的模型必須區分誤判，請使用 recall。 當模型需要區分誤判時，請使用 precision。 您也可以使用 F1 分數。 這個分數是 和 recall之間的precision調和平均數，因此不會受到大量真判或真負數的影響。 您可能需要在測試階段手動計算某些計量。

或者，若要增加分類為詐騙的交易數目，您可以手動使用稱為合成少數過度取樣技術（SMOTE）的技術。 SMOTE 是一種統計技術，使用啟動載入和最接近的鄰居 （KNN） 來產生少數民族類別的實例。

模型訓練

針對模型定型，Python SDK 預期數據格式為 pandas 數據框架格式或 Azure 機器學習 表格式數據集。 您想要預測的值必須位於資料集中。 當您建立定型作業時，您會將 y 資料行當做參數傳入。

以下是具有批註的程式代碼範例：

data = https://automlsamplenotebookdata.blob.core.windows.net/automl-sample-notebook-data/creditcard.csv
dataset = Dataset.Tabular.from_delimited_files(data)
training_data, validation_data = dataset.random_split(percentage=0.7)
label_column_name = "Class"

automl_settings = {
    "n_cross_validations": 3, # Number of cross validation splits.
    "primary_metric": "average_precision_score_weighted", # This is the metric that you want to optimize.
    "experiment_timeout_hours": 0.25, # Percentage of an hour you want this to run.
    "verbosity": logging.INFO, # Logging info level, debug, info, warning, error, critical.
    "enable_stack_ensemble": False, # VotingEnsembled is enabled by default.
}

automl_config = AutoMLConfig(
    task="classification",
    debug_log="automl_errors.log",
    training_data=training_data,
    label_column_name=label_column_name,
    **automl_settings,
)

local_run = experiment.submit(automl_config, show_output=True)

在程式代碼中：

1. 將數據集載入 Azure 機器學習 表格式資料集或 pandas 資料框架。
2. 將數據集分割成 70% 定型和 30% 驗證。
3. 為您想要預測的數據行建立變數。
4. 開始建立 AutoML 參數。
5. 設定 AutoMLConfig。
   1. task 是您要執行的機器學習類型： classification 或 regression。 在此案例中，請使用 classification。
   2. debug_log 是寫入偵錯資訊的位置。
   3. training_data 是載入定型資料的數據框架或表格式物件。
   4. label_column_name 是您想要預測的數據行。
6. 執行機器學習作業。

模型評估

良好的模型會產生實際且可操作的結果。 這是詐騙偵測模型的挑戰之一。 大部分的詐騙偵測模型都會產生二進位決策，以判斷交易是否為詐騙。 決策是以兩個因素為基礎：

• 分類演算法傳回的機率分數介於 0 到 100 之間
• 企業所建立的機率臨界值。 高於閾值會被視為詐騙，且低於閾值會被視為非詐騙。

Probability 是任何分類模型的標準計量。 但對於是否封鎖帳戶以防止進一步損失的決定，在詐騙案例中通常不夠。

在此解決方案中，會建立帳戶層級計量，並納入企業是否應該採取行動來封鎖帳戶的決定。 帳戶層級計量會根據這些業界標準計量來定義：

這些計量是詐騙管理員的寶貴數據點。 經理會使用他們來取得帳戶風險的更完整畫面，並決定補救。

模型化和重新定型

預測模型需要定期更新。 隨著時間推移，隨著新的和不同的數據可供使用，必須重新定型預測模型。 對於犯罪活動新模式頻繁的詐騙偵測模型來說，這尤其如此。 當行動應用程式記錄的遙測因為修改推送至應用程式閘道而變更時，也會變得必要。 為了在此解決方案中提供重新定型，系統會記錄提交用於分析的每個交易，以及對應的模型評估計量。 經過一段時間後，會監視模型效能。 當它似乎降級時，會觸發重新定型工作流程。 重新定型工作流程中會使用數個 Azure 服務：

• 您可以使用 Azure Synapse Analytics 或 Azure Data Lake 來儲存歷史客戶數據。 您可以使用這些服務來儲存從內部部署來源上傳的已知詐騙交易，以及從 Azure 機器學習 Web 服務封存的數據，包括交易、預測和模型評估計量。 重新定型所需的數據會儲存在此數據存放區中。

• 您可以使用 Data Factory 或 Azure Synapse 管線 來協調數據流和重新定型的程式，包括：

  • 從內部部署系統擷取歷程記錄數據和記錄檔。
  • JSON 還原串行化進程。
  • 數據前置處理邏輯。

  如需詳細資訊，請參閱使用 Azure Data Factory 重新定型和更新 Azure 機器學習 模型。

• 您可以在 Azure 機器學習 中使用藍綠部署。 如需以最短停機時間部署新模型的相關信息，請參閱在線端點的 保管庫 推出。

元件

• Azure Functions 提供事件驅動的無伺服器程式代碼函式和端對端開發體驗。
• 事件中 樞是完全受控的實時數據擷取服務。 您可以使用它，從任何來源每秒串流數百萬個事件。
• 金鑰保存庫 加密雲端應用程式和服務所使用的密碼編譯金鑰和其他秘密。
• Azure 機器學習 是端對端機器學習生命週期的企業級服務。
• AutoML 是自動化機器學習模型開發的耗時反覆工作的程式。
• Azure SQL 資料庫 是專為雲端建置的最新、完全受控關係資料庫服務。
• Azure Synapse Analytics 是一項無限制的分析服務，可將數據整合、企業數據倉儲和巨量數據分析整合在一起。

技術考量

若要為持續運作的雲端式基礎結構選取正確的技術元件來進行詐騙偵測，您需要瞭解目前的需求，有時也模糊不清。 此解決方案的技術選擇是以可協助您做出類似決策的考慮為基礎。

技能

請考慮小組目前設計、實作和維護解決方案的技術技能集。 雲端和 AI 技術可擴充可用於實作解決方案的選項。 例如，如果您的小組具備基本數據科學技能，Azure 機器學習 是建立模型和端點的絕佳選擇。 使用事件中樞的決定是另一個範例。 事件中樞是易於設定和維護的受控服務。 使用 Kafka 之類的替代方法有技術優勢，但這樣做可能需要訓練。

混合式操作環境

此解決方案的部署橫跨內部部署環境和 Azure 環境。 服務、網路、應用程式和通訊必須有效地跨這兩個基礎結構運作，以支援工作負載。 技術決策包括：

• 環境如何整合？
• Azure 數據中心與內部部署基礎結構之間的網路連線需求為何？ Azure ExpressRoute 是因為它提供雙行、備援和故障轉移。 站對站 VPN 不提供工作負載所需的安全性或服務品質（QoS）。
• 詐騙偵測分數如何與後端系統整合？ 評分回應應與後端詐騙工作流程整合，以將交易與客戶或其他案例管理活動的驗證自動化。 您可以使用 Azure Functions 或 Logic Apps 來整合 Azure 服務與內部部署系統。

安全性

在雲端中裝載解決方案會建立新的安全性責任。 在雲端中，安全性是雲端廠商與客戶租用戶之間的共同責任。 工作負載責任會根據工作負載是 SaaS、PaaS 或 IaaS 服務而有所不同。 如需詳細資訊，請參閱 雲端中的共同責任。

無論您是要走向 零信任 方法，還是努力套用法規合規性需求，確保解決方案端對端都需要仔細規劃和考慮。 針對設計和部署，建議您採用與 零信任 方法一致的安全策略。 採用原則，例如 明確驗證、 使用最低許可權存取，並 假設外泄 會增強工作負載安全性。

明確 確認是檢查和評估存取要求的各個層面的程式。 以下是一些原則：

• 使用強式身分識別平臺，例如 Microsoft Entra ID。
• 瞭解每個雲端服務的安全性模型，以及如何保護數據和存取。
• 可能的話，請使用受控識別和服務主體來控制雲端服務的存取。
• 在 金鑰保存庫 中儲存金鑰、秘密、憑證和應用程式成品，例如資料庫字串、REST 端點 URL 和 API 金鑰。

使用最低許可權存取 可協助確保只授與許可權，以符合特定商務需求，從適當的環境到適當的用戶端。 以下是一些原則：

• 藉由限制元件或資源透過角色指派或網路存取的存取量來分割工作負載。
• 不允許公用存取端點和服務。 除非您的服務需要公用存取，否則請使用私人端點來協助保護您的服務。
• 使用防火牆規則來協助保護服務端點，或使用虛擬網路隔離工作負載。

假設缺口 是指導設計和部署決策的策略。 策略是假設解決方案已遭入侵。 這是透過規劃偵測、回應及補救安全性威脅的方式，在工作負載中建置復原能力的方法。 針對設計和部署決策，這表示：

• 工作負載元件會隔離並分割，讓一個元件遭到入侵，將上游或下游元件的影響降到最低。
• 遙測會主動擷取和分析，以識別異常和潛在威脅。
• 自動化已就緒以偵測、回應及補救威脅。

以下是一些要考慮的指導方針：

• 加密待用和傳輸中的數據。
• 啟用服務的稽核。
• 將稽核記錄和遙測擷取並集中到單一記錄工作區，以利分析和相互關聯。
• 啟用 適用於雲端的 Microsoft Defender 掃描潛在易受攻擊的設定，並提供潛在安全性問題的早期警告。

網路功能是最重要的安全性因素之一。 根據預設，Azure Synapse 工作區端點是公用端點。 這表示您可以從任何公用網路存取它們，因此強烈建議您停用工作區的公用存取。 請考慮使用已啟用受控 虛擬網絡 功能來部署 Azure Synapse，以在工作區與其他 Azure 服務之間新增隔離層。 如需受控 虛擬網絡 和其他安全性因素的詳細資訊，請參閱 Azure Synapse Analytics 安全性白皮書：網路安全性。

下載此架構的 Visio 檔案。

下表包含銀行解決方案中每個解決方案元件特有的安全性指導方針。 如需良好的起點，請檢閱 Azure 安全性基準，其中包含每個個別 Azure 服務的安全性基準。 安全性基準建議可協助您選取每個服務的安全性組態設定。

如需詳細資訊，請參閱 零信任 指引中心。

延展性

解決方案必須透過尖峰時間執行端對端。 處理數百萬個持續抵達事件的串流工作流程需要高輸送量。 規劃建置測試系統，以模擬磁碟區和並行，以確保已設定並調整技術元件，以符合所需的延遲。 這些元件的延展性測試特別重要：

• 處理並行數據流的數據擷取。 在此架構中，會使用事件中樞，因為它的多個實例可以部署並指派給不同的取用者群組。 相應放大方法是較佳的選項，因為相應增加可能會導致鎖定。 如果您計劃擴大從移動銀行進行詐騙偵測，以包含互聯網銀行管道，相應放大方法也更合適。
• 管理及排程程式流程的架構。 Azure Functions 可用來協調工作流程。 為了改善輸送量，訊息會以微批次方式批處理，並透過單一 Azure 函式處理，而不是處理每個函式呼叫的一個訊息。
• 處理剖析、前置處理、匯總和記憶體的低延遲數據處理程式。 在本文所依據的實際解決方案中，記憶體內部優化 SQL 函式的功能符合延展性和並行需求。
• 模型評分以處理並行要求。 使用 Azure 機器學習 Web 服務，您有兩個選項可調整：
  • 選取生產 Web 層以支援 API 並行工作負載。
  • 如果您需要支持超過 200 個並行要求，請將多個端點新增至 Web 服務。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主要作者：

• 凱特·巴羅尼 |首席客戶工程師
• Michael Hlobil |主要客戶工程經理
• Cedric Labuschagne |技術計劃管理員
• Frank Garofalo |首席客戶工程師
• 謝潑德 |高級服務工程師

其他參與者：

• 米克·阿爾伯特 |技術寫入器

下一步

• 由單一 Azure 函式支援的快速、無伺服器、巨量數據管線
• 考慮無伺服器數據流案例的 Azure Functions
• App Service 環境的網路考量
• 事件中樞
• 金鑰保存庫
• Azure Machine Learning

相關資源

• AI 架構設計
• 比較 Microsoft 機器學習產品和技術
• Azure Functions 事件中樞的效能和調整指引
• 監視 Azure Functions 和事件中樞
• 什麼是 Azure Machine Learning 管線？