所在位置:首頁 -- 軟件設計 -- 正文

架構師如何才能夠設計一個安全的架構


發布時間:2013-10-4  來源:admin

【IT168技術】架構師不可能做到全知全能,但是仍然擔負著成功交付可用的解決方案的任務。滿足安全需求常常是其中不可或缺的一環,而且這一點常常沒有明確指出。本演講從整體上討論架構的安全性,比如如何撰寫安全的代碼、部署中的安全、架構層的物理隔離、加密、證書的使用等等方面。

隨著互聯網安全形勢的日益嚴峻,對于架構師們來講,為什么需要一個安全的架構以及怎么建設安全架構成為了迫在眉睫的重要任務。為什么來這里講安全,很多人沒聽過澤西島,在英國的南部,是一個離岸的轄區,金融機構在島上非常盛行,對安全很重要,要安全維護,要有系統享受低稅,很多做JAVA的項目,大部分澤西的工作,離岸的銀行小公司對安全特別關注的。

糾正系統架構的安全認識

肯定是重要的。特別澤西島有自己交易的信息、銀行的信息、養老金的信息,所有的資料在澤西島里面安全保護起來。離開澤西島也要保障安全,如果不把安全做好,肯定要有糟糕的事情發生。

我講一些最近大家都知道的一些安全的漏洞,比如說Linkedln,有一些密碼泄露了。也是最近轟動的事情。

安全適用于方方面面,我們講軟件架構的時候,并不只是看一個地方來求安全,安全應該在整個完整的軟件系統當中,都能滲透在安全中,包括所有的級別層所有的元件都需要做到安全。很多人認為安全是人份認證、授權,很多人認為安全是兩個問題,但是安全還有其他的問題,比如說防黑客、防攻擊、加密等。

安全這個問題很難對現有的代碼進行安全的加裝或改裝。如果安全出現問題,要解決安全問題,從架構的基礎上來解決的。如果架構的問題一開始沒做好,事后補相當困難。跟性能、擴展性都是很重要的,一開始沒有照顧好的話,未來提升就很難了。

安全在整個軟件架構的角色當中是怎樣的位置

我們需要在整個軟件開發過程中都要進行考慮的問題。我曾經講過一個故事,一個面向公眾的互聯網網站。這個網站是一個針對當地澤西島的一個聽眾,澤西島10萬人,是很小的用戶群,是一個全新的互聯網系統軟件服務。這個互聯網服務,可以去登陸獲得一個用戶名,之后獲得這些權限。他們請我去看軟件系統,我去看軟件系統的時候,假裝用戶去體驗一番。

我很快發現我可以做跨站的腳本攻擊。比如說創造賬戶,有名字、地址、電郵、電子卡信息。而在地址這一欄,可以寫Java腳本,可以注入Java腳本。這個例子是很小的例子,可以對網站做的攻擊遠遠不止這一點,有很多東西可以做。

我只用了五分鐘、十分鐘就發現了這些漏洞。當然,這個網站還沒有完全上線,只是進行前期的測試,在這個時候發現問題算是萬幸。其實在登陸面可以創建自己的密碼,很多網站可以是1位到20位需要多少的標點。有些網站需要密碼的強度。這個網站也是一樣,列出網站應該這樣。登陸賬戶的時候,我說密碼太煩了。前臺認證并沒有很復雜,隨便一個詞就可以接受了,有些比較弱,有攻擊密碼。

我在做銀行互聯網的時候,有做一個雙重認證。在頁面看十分鐘,HTTP的對話就超時了,為什么超時?這是安全的功能。比如說共享一個電腦,在網吧、咖啡店上網的話,有超時的保護。有不同的安全要求。回到我剛才講的網站,這個網站肯定不是登陸之后一直在線的,對話的時段是非常短的,因為里面有一些非常機密的個人信息。但是,你登陸了網站之后,登陸永遠不超時。把游覽器關掉再打開,永遠不會中斷,就算點登出,不會登出,管理有問題的。我們要做安全的策略性平臺,如果有這么多的漏洞,是非常危險的。

這個項目正在進行用戶的接受度檢測的過程,還沒有上線,他們請我去做了檢查。經過了各方面的檢查,他們說我們只有四個星期就上線了,找了很多問題,項目四個月之后才能上線,很多顧客對這個問題根本就不敏感。

架構師是“T”型人才 是一個建筑師

要有知識的深度,同時也有不同方案的廣度,我們面臨的軟件架構師是一個建筑師,這種解決方案必須要知道不同的解決方案不同的軟件開發都需要通才的能力。我們從安全的角度來說,軟件架構師的工作非常復雜的,特別是windows的環境有很多學習的地方。廣度也很重要,有各種各樣的安全問題,在整個架構、編碼的過程中,不同地方都會出現漏洞。如果沒有足夠的經驗,甚至不知道哪個地方有可能出問題。比如說我們項目的架構師可能是一個通才,有一定的深度,有技術的專長,必須要知道在哪些地方有可能出現問題。

我們面臨的風險是什么呢?

攻擊、黑客、宕機、拒絕服務、密碼泄露、機密信息外泄、安全受損等很多問題都可能來自于安全的問題。這顯然是我們從架構角度認真對待不同的風險。這就提出一個很有意思的問題,我們是不是可以樣樣精通呢?我問過“T”型的人才,我們有知識的深度,如果是Java的架構師,必須要真的理解Java,我們要做高性能的系統,這方面的知識,怎么做可擴展性,還有高可靠性。

必須要保持這種意識

所有不同的領域我們都有一定的寬度和廣度,安全是其中一點。我們之前看到編碼是整個所有活動當中的中心,是不是所有的知識都可以做編碼呢?如果是一個小小的項目可以做自己的編碼,同時也應該知道可用性、安全性以及擴展性的種種知識。這是不是意味著樣樣都精通呢?我給大家講安全課,但是我不是安全專家。但是安全是我們作為架構師必須有意識、必須有概念,而且要知道安全環境不斷的改變,有新的不同攻擊、不同黑客,必須要保持這種意識。所以我們必須有安全的意識,而意識是一個關鍵詞。

剛才講了“T”型人才,是一個通才型的專才。做軟件團隊的時候,可能有一個人來做這個工作,可能有一個專門軟件架構師來做技術主管的角色。這個人就是我們的通才化的全才。但是你能找到這樣一個人嗎?我們可能要面試很多人、招聘很多人,是不是能找到通才化的人才呢?不一定的。最近我建立一個系統,是一個混合項目,我們可以有多個人進行架構的支撐,共同協同工作,聯合起來形成了足夠寬度和深度,一方面有通才型的專才,另一方面專家提供深度的支持。

一般我做的項目里面可能會請一個專家,專家有相關的經驗,有些是沒有的。給大家看一個很有意思的博客,在英國看到的。如果系統里面有SQL的出入,就有流程或者基礎設施的問題。如果你的問題有安全隱患的話,系統安全隱患,就是說明現在做錯了,要看哪些地方做錯了,如果沒有這方面的專家怎么辦?或者根本沒有意識到潛在的安全問題或者已有的安全問題。

安全怎么融入到系統當中

從最根本的角度來看安全有什么要求。就像十年之前搞架構的時候,有哪些具體要求,哪些東西要做哪些不要做的。必須要清楚地知道,在建造架構的時候哪些東西需要做,怎么才能高效。我覺得安全也是一樣,很多人都是從用戶的角度來獲取用戶的需求。用戶的角度確實不錯,希望能夠找一些好的、簡單適用的。他們不是技術性的人才,視角不是特別獨特。在編寫用戶表述的要求時,有不同的模板。所做的一切要清楚在你的系統里面,用系統的人分成哪些類的。

去年我做了一個項目的架構分析,大概里面有兩到三百個使用者所提供的一些要求,用戶扮演著不同的角色。到底這些用戶分成哪些?比如說超級用戶還是管理員,還是一般性的用戶。但是分不出來類。我覺得挺有意思的。

如果我設計軟件的話,必須要知道軟件針對的受眾是誰,誰會用。今天早上給大家看圖,第一個就是上下文背景,中間是系統,下面還有與之溝通的系統,最上面是我們講的用戶。我們知道到底哪些類型的用戶在使用我們的系統。為什么這點很重要?從安全角度講很重要。問這個團隊到底懂不懂安全,誰在用我們的系統?這些人用我們的系統,有什么樣的功能?我們這些使用者所提供的一些,也從相關來講比較高端的視角來分析一下類別。

對于這方面的信息不是已經過時了,非常適用的。在英國一些咨詢管理公司,要求做成文件發給我們,尤其是技術方面的要求。技術要求包括擴展性、安全、性能等。這些從特點來講比較技術性的,而且非常詳實。寫這些要求的人,不是技術出身的,是商界出身的,他也不清楚產品規格里面細節多細合適,所以來一句系統是非常安全,對于系統的安全來一句就夠了。作為架構師這句話牛頭不對馬嘴,確實要做到安全。

用戶或者SQL的攻擊注入時,怎么樣做到安全?

很多英國的公司從安全的角度講,做得很爛,因為團隊不知道安全到底意味著什么。可能在網上隨便問一些人到底該怎樣做。

作為架構師要分析需求的話,并不是說做大型的前端設計,而是做一些簡單的,獲取、捕獲使用者的要求,做高級的架構設計,比較要考慮到擴展性、安全,如果沒有考慮到這些,在打造架構的時候,可能會丟失非常寶貴的元素。可以開一些研討會、交換文件,這種工作坊和小型研討會的形式非常好,知道使用系統的是這部分用戶。

客戶給的要求是系統非常安全,就要問他非常安全是有多安全,工作坊可以面對面的交流,誰在用我們系統,哪些方面的內容影響了他們對系統的使用,為什么會這樣?這樣會有非常具體的用戶對系統的要求。除了捕獲信息之外,還要置疑他們。我們團隊必須要不斷的置疑挑戰我們一開始所制定出來的具體要求。到底我們開發的時候優先級別會怎樣。覺得要求根本沒必要,換一種方式行不行,我覺得就已經夠了,要挑戰不同的要求,不僅是功能性的,還有非功能性的,比如說安全,也要跟客戶談一談。每次在系統里面引入安全的時候,要做一些權衡、妥協、讓步。

一般來講,典型的讓步、取舍是可用性、易用性和復雜性。也就是說,安全的話更復雜了。比如說我去銀行要做,ID非常長,記不下來,輸入密碼登陸,到了第二頁,要輸入安全代碼,有一個小鍵盤,類似于口令牌,隨即生成輸入進去。等我通過這么多安全檢查進這個網站的時候,對話已經超時了,我輸入這么多的密碼,已經查不到我賬戶信息了,這是非常長、非常復雜的過程,用電子安全指令等。確實很安全,但是影響了便捷程度。這時要做取舍,是易用還是復雜安全性。

如果要勝任軟件架構師的角色,需要多種能力

理解要求非常重要,作為架構師必須理解要求是什么,比如說不能只做前期的設計,交給后期去實施,這不是我們做的,但我們必須要知道安全的要求,安全的要求必須要吃透。安全是一個非常關鍵,從架構師的角度來說,認真對待安全的要求。特別是項目的技術主管,要教練和指導你的員工,作為技術主管來說,必須有這個能力。而且安全搞不好是一個大風險。

安全問題怎么樣能夠在架構里面得到詮釋

安全可以融入到所有領域的,現在看到的有三級顯示,Web服務器、應用服務器、數據庫。在Web服務器上避免攻擊,應用服務器獲得授權的人才能進入,數據庫是確保數據安全保存在這里。中間部分是保障基礎設施的安全,包括防火墻等。稍候會講怎么有效獲得授權。

這是一種非常常見也是非常傳統打造安全的方式。可能在服務器上放很小的代碼,數據庫里面放很多數據,中間應用服務器獲取這些相關信息。因為肯定關注安全,信息存儲是否安全。

稍候看一看這些架構,看到Web服務器使用了相關安全服務,這是很常見的,但是這些所謂的Web服務非常不安全,比如輸入ID開發工具,你的Web服務創建了一些本地的組建,你發現這里不需要授權,隨便什么人都可以進來,因此在這個領域我覺得安全是可以發揮重要的作用的。

我們在做架構的時候,如果把服務器從物理上分得開,不一定真正安全了。物理分開的話,中間信息傳輸出現影響。每個層級有安全,不同的層級間的安全很重要的。如果從物理上分割開來,中間的聯系也會成為攻擊的對象。

千萬不要把編碼放的到處都是,放在核心中央層

這樣的話攻擊你就只可能攻擊你表面,核心保護很好。這里有非常有意思的問題,為什么用物理上分開來的應用服務器,人們覺得集成實時的,總是搞架構把應用服務器分開來,但是我們也可以找一些其他的方法,現在有很多互聯網的創業公司就是這么做的。我想希望大家好好想想你干嗎這么做,做一件事情必須事出有因才行。這實際上就是我們講得做出取舍。安全得到保障,復雜性獲得一些影響。在我們的安全因素的話,講到最小的特權原則。只有必須要發生的事情才能發生,不能把所有的東西全部部署到服務器上從來都不用。

許可一個進程操作的話,要確保進程必須要操作的,其他不需要操作不要放在這里。這點是所有軟件架構師在系統里面必須要牢記的。

怎么通過不同的方式來把安全引入到系統里面

現在講驗證、授權、審核是三個比較常見的方法。首先,驗證。我是用戶,是誰呢?權力是什么?用什么東西?這很重要,可以幫助你了解到用戶的需求以及不同類型的用戶在系統里面扮演不同的角色該怎樣具體做呢?有這樣的系統怎樣能夠做好本地的驗證和授權。其實很多方法都可以。

先來看看一個簡單的兩級的方式,Web服務器和數據庫直接進行對換。講到安全、認證、授權最簡單的方法,系統認出你的用戶,在系統里面有一個用戶的名單,有他們使用的權力,通過映射的方式,客戶來了映射能做什么,是不是最高效能,不一定。

早上說過我們有不同的選擇,要解決這樣的問題,選擇很多的,還有另外一個方法,比如說設計自己的架構,不把你的數據放在數據庫里,大的企業會有一種主動的目錄和一些算法,是包含了用戶和他的一些資格說明,這樣的話就可以加以利用了。你不會把用戶放在你的數據庫里,可以把用戶放在別的地方,這樣的話管理的負擔也小了。有新的用戶在中間的注冊器里面注冊新用戶就可以了。

但也許它的角色放在數據庫,因為不同角色有不同的授權。所以用戶和他的資歷放在外面,但是角色放在數據庫里,這也是很好分解的辦法。或者甚至把授權也放在主動的目錄當中,形成不同的群組,這是可以選擇的方法。但是會不會比之前的方法更好呢?同樣,這并不是我能回答的問題。有些企業、有些組織很愿意做這種,覺得這個夠了,可以對于用戶的目錄專門存放用戶的信息。但是其他的一些企業、一些組織并不喜歡把你自己的群組放在自己的服務器上。有些時候可以,有些時候不愿意使用。

還有其他的方法,可以用安全令牌的服務,有人做身份基金會的工作,實際上就是把安全進行集中化,不管是身份驗證還是授權都能夠集中起來,我兩年前做的一個項目,有一個單獨的令牌的系統,這里面給我們帶來的復雜性是不可想象的,本來只有一個人做這個項目,壓力非常大,非常復雜。這也是一種選擇。對某一種企業來說,也許是最好的選擇。

哪一個方案是最“好”的?其實沒有所謂的最好的方案,永遠只能對你來說最好,對這個環境來說最好,所以哪個是最好呢?還是回到今天早上講過的,從高層的角度上了解我們的需求,了解我們環境的約束性、局限性。如果在大企業工作的話,可能會有一個主動的目錄服務器了。可以去找這個有關的部門,可以找你服務器來做驗證。可不可以把決策和授權放在目錄當中,可以選擇最好的解決方案。

有一個大的英國超市,用明文來記密碼,密碼以明文的形式寄到郵箱,回歸到之前的架構,如果數據庫是夠安全的話,明文也沒問題的。對于這篇文章之后,有一個很好的明文建議,如果用明文密碼會加密,而且是散列的處理。我不是一個安全專家,但是我知道至少有不同的方法來把密碼進行分類散列,比如說用一些隨機的數字進行加密和散列,這都是很好的進行密碼散列的方法。當然我們也選擇一個最適合我們的方法。

審查、審計也是一方面,我們要有一個審計的線索。比如說我們在澤西島是離岸的環境,做很多交易,必須知道哪些用戶做了什么?為什么要這么做?因為有人對這個網站提出一些索賠,丟失了信息我們要追訴回去,看一下他的信息怎么丟的,有沒有修改。

怎么能寫出安全的代碼?

網上有很多信息,主要有兩個主流:第一,要避免數字被修改。第二,限制接入。

當然免疫性很好的,如果免疫的話就不能修改。這是一個很好的屬性。如果這個數據有一定的對象,而這個對象數據是不能修改的,免疫了就不能修改了,所以從根本上來說是安全的。如果有功能性的語言,用這個數值改變,因為免疫不能改變了。你想象一下,有一定的人、把這個人加入到列表當中。怎么樣讓他把所有的人列出來呢?也許在下面給一條getPeople的指令。

給一些簡單的建議,比如說用一些接入的修訂詞,特別是對外API的時候,要有各種的假定,比如說接入的修飾詞和修飾條件。如果所有的東西都是對外公開,沒有安全的問題才怪!

scott/tiger,有人在笑,很多人拿到密碼都沒有改,用戶和密碼缺省或者原始的數據密碼都不改,這必須要改,改成一個比較有利的密碼。

講到數據的時候,真的希望能夠限制消費者對數據的接入,限制消費者對數據的使用,這可以幫我們收載他們的訪問范圍。不管我們的網站在什么地方,我們用SQL的數據庫怎么做呢,我們用特別的一些代碼通過SQL進行數據庫的接入,有些時候不喜歡這種方法,覺得過程非常復雜。雖然復雜,但是有一個精簡、簡單、安全的API,很多人用SQL,就是為了安全性。

2000年的時候,我在一個小的電商公司做網站,他們首次在搞商務網站。他們有一個電商網站,而且是一個盒子,只需要拿一個光盤裝到系統上就是一個電商網站了。想存儲他們的信用卡號碼。客戶回到電商時,不需要把信用卡再輸一遍,這是盒子提供的,總要有一個地方來放信用卡信息吧!他們看一看數據庫里面有沒有欄目沒有用到,他們發現中間名沒人用,就把中間名放信用卡了,只用輸入(英文),沒有經過加密,對信用卡進行外鍵的字符串。我們也知道對這樣的外鍵的字符串可以破解的。這種安全只不過是把字符串進行排列,并沒有進行任何的安全加密,只不過支付串操作兩次就已經萬無一失了。

我們講過數據代碼,也應該談一下配置、部署,所以有數據庫。網絡服務器要跟數據庫進行溝通的話,必須要用戶名和密碼。數據庫的用戶名和密碼什么地方?往往是在網頁服務上,往往都是明文。如果有人攻擊網頁服務器,必須提取文件系統,提取之后可以看到明文的文件,這個發生了很多。

怎么樣解決這些問題呢?

要確保這個信息加密。用Java系統也有加密的配置辦法,這都有辦法,只是有沒有這個意識。我們可以用一些CQL服務器受信任的連接就可以避免了。

之前我在澤西島做的項目是離岸銀行,他們很重視,我們做自己的虛擬機、手提電腦來寫代碼,但是要部署到銀行系統,我們要用一些連續的工具放入U盤上,把U盤交給銀行的人,接入另外一個網絡,裝入軟件當中。這里我們的開發團隊和部署團隊是物理隔離的,避免了開發團隊能夠染指生產的系統。

問題在做部署的人根本不太理解做開發的原意,不是一個技術人員。所以我們在自己廢寢忘食的寫了這么多代碼,交給他之后,不懂怎么部署,物理隔離不能保障安全,這個過程或者流程肯定有漏洞的。不是說一定能解決這樣的問題。

生產的資質、資格也是一個問題。比如說有一個經過測試的環境,這個環境把它放入生產的系統當中,當中有這個隔離。把生產的用戶名和密碼放在什么地方呢?也許你可以放在配置服務器的一個地點,但這個要看多么看重安全性,如果連續交付很有意思了,連續交付有關的資質就要考慮怎么存放。

運行時間方面和安全有什么關系呢?

這里說到重要的原則“最小特權原則”,我們看一看這個模型。在Java應用里面可以用Java2的安全模型,允許你做一部分的工作,比如說只能進入到這方面的網絡或者只能用這部分的接口,這就是Java的安全模型。如果網站被黑的話,肯定會直接攻擊里面用戶。一般不會這么做,會密碼也不改,不限制賬戶的使用,導致黑客很輕易獲取信息。

之前我在電商工作過,就有一些信息方面的問題,找到他們的日志文件,發現有很多的錯誤信息,成千上萬的錯誤信息。人們要輸入信用卡信息,信用卡信息也都在日志文件里面。在日志文件里面,地址、名字、信用卡信息以及信用卡盜竊事件都有。

我們還要有效監控管理界面方面的安全,不能把東西放在云端上就覺得什么事都搞定了,還要看監控確保運行合理合適。我在做顧問的時候,曾經幫一個電商的網站做很短的項目。如果我打開我的瀏覽器連上網,完全可以看想看的頁面,沒有最基本的二進制密碼保護。

架構師要知道基礎結構

我是項目上的軟件架構師,不做基礎設施的設計,但是不必須要了解到防火墻的設置等。因為確保基礎的設施才能支持我們軟件的架構。另外,從軟件的角度來講,也非常的重要。最早不是我做的,我做的很多系統都是在澤西島,因為很多的數據都有地域限制,必須要用本地的服務器,要把服務器信息拿出去的話,第一件事情是把原來的安全保護、防火墻沒有用的東西都拿走,這樣可以減少空間內容。要和基礎設施團隊DMZ來談一談防火墻等。從軟件架構師角度來講,要使用web服務或者RMI等不同服務,軟件架構團隊和基礎設施團隊必須要有溝通才行。

攻擊者、黑客以及我們的漏洞

我在倫敦工作的時候,很多是做公司內部的,回到澤西島的時候,做了很多互聯網的界面,影響到數據安全性。如果大家覺得講得這些內容比較陌生的話,希望大家能夠好好地看一看開源的應用安全項目。

列出了10個最主要的,注入、跨站腳本攻擊、驗證、對話管理等。從安全角度講是值得一看的東西。有一次看了CQL的注入,我不是一個安全專家,但是我看了CQL注入知道成為安全隱患,因為電擊鏈接可以看到很多信息。

現在看到的是中文版,叫做OWASP,中文版的,喜歡網站是因為告訴我們最主要的攻擊方式,給一些例子,該怎樣修復這些漏洞,避免這些攻擊再次發生。

最近經歷一件事是很多系統都要做深度測試。找一些外部第三方的團隊或者公司來看不看能不能黑你的系統,看系統到底多牢固。我們會發現他們攻擊的時候,很多之前沒有注意到的漏洞浮出水面。這些團隊給一些例子,既然找到漏洞,告訴我們該怎樣把漏洞一個個補好。非常建議第三方來做測試。

最后總結

安全非常重要,但是安全也非常復雜。作為一個軟件的開發員、程序員,要做到敏捷、持續的交付、關注模式,非常流行的詞匯。但是安全不是熱門詞匯,要注意安全的重要性。比如說做網銀、網絡界面不能忽視安全。今天上午講了文本介入,搞文本輕一點就行了,不能太復雜,做一個軟件的架構,給別人用,不給文件不知道安全怎么做,不知道安全怎么做,可能會加一些編碼,這些編碼反而讓你的安全系統安全用不上了,可能一兩年之后安全徹底失明了。因此我們提供不太厚的文件,里面有關鍵信息。

剛才講了怎么樣收集用戶的一些要求,把它進行排序。當然不能完全依賴他的想法,但是要讓他知道安全方面哪些最重要的。安全很重要,而且適用于整個軟件架構的所有環節。從外部端到數據庫端,從跨件的腳本到注入等,都要確保里面內容是安全的。上下文非常關鍵,這里有一些安全方面的最佳實踐。如果之是照搬別人的非常復雜,所以要知道哪些是需要取舍的,做這些風險會帶來什么影響,會泄露什么數據?這些數據有價值還是沒價值的?用這些為什么而用,提高應用性和復雜性。

一個人不可能樣樣精通,我對安全不是專家,但是對安全要了解一些情況。我們知道行業不斷變化,速度非常快。既然不可能把所有的知識都學的很透徹,至少我們能夠粗淺的像蜻蜓點水了解一些東西。另外,千萬別做一個不負責任的軟件架構師。因為我們架構師就像一個領導者一樣,確保所有的工作都能有效。

中国比特币暴涨 新疆时时彩开奖jg 山西福利快乐十分走势图 山西快乐十分走势图app 云南时时怎么玩 香港正版免费资料大全一 上海快3走势图上海快三 快速时时计算方法 三十元的刮刮乐中奖图片 金走势图 转让黑龙江时时机器 陕西快乐十分钟走势图电脑版 时时重庆分析软件 体坛网排列五走势图 北京快三开奖结果一定牛百度 开奖特马码 时时彩龙虎和