牽涉到網路的資訊系統在實作安全管制功能時必須包含三種層次，分別是身分驗証的層次，權限管制的層次，以及安全通訊的層次。所謂身分驗証的意思就是系統的使用者必須能夠通過系統的身分驗証機制的檢查，才能夠登入資訊系統，然後使用系統提供的功能，至於能夠使用系統提供的那一些功能，需視使用者獲得的權限而定，這就是權限管制的功能。至於安全通訊的意思就是對重要的機密資料加上加密或是簽章的處理，確保機密資料的私密性和完整性。
這次題目討論的是一些系統資訊安全的基本概念。
正確答案：C
說明：
不可以被所有人知道的機密資料可以加上加密保護，欲將加密過的資料解密成加密之前的內容，解密者必須取得解密用的金鑰，無法取得解密用金鑰的使用者將無法將加密過的資料還原成加密之前的內容。如果解密用的金鑰被很多人得知，則機密資料將不再是機密。
無法取得解密用金鑰的使用者只要使用運算速度極快的電腦，以排列組合的方法，猜測解密用金鑰的內容，只要時間夠長，總有猜對金鑰內容的一天。例如長度為80位元的金鑰，總共只有280種排列組合方式，金鑰越長，排列組合的數目也就越多，被猜中的機會也就越低。如果因為執行效能的需求，選擇使用長度較短的金鑰，為了確保加密資料的安全，可以搭配定期更換金鑰的策略，降低金鑰被猜中的機會，千萬不要為機密資料加上加密處理之後就不再理它，因為加密後的機密資料存放久了，等於給予有心人士充裕的時間猜測解密機密資料的金鑰的機會。
金鑰的長度直接影響金鑰排列組合的數目，金鑰的長度越短，可能的排列組合就越少，被猜中的機會也就越高，反之，金鑰的長度越長，可能的排列組合就越多，被猜中的機會也就越低，雖然比較安全，但是因為金鑰的長度越長，加密/解密的效率也就越差，因此並不是所有需要對機密資料執行加密的場合都適合選用長度較長的金鑰，例如對大量的資料進行加密就適合選擇長度較短的金鑰，以提升資料加密/解密的效能。不過使用長度較短的金鑰對資料進行加密的缺點是被破解的風險較高。要解決金鑰被破解的風險，定期更換金鑰是不錯的做法。
表1列有對稱式加密與非對稱式加密演算法使用的金鑰長度與機密資料保存期限的關係。
表1：金鑰長度與機密資料保存期限的關係 資料保存期限 現在~2010年 現在~2030年 現在~2031年以後 對稱式加密金鑰建議使用的長度 80位元 112位元 128位元 非對稱式加密金鑰建議使用的長度 1024位元 2048位元 3072位元 表1所列的是金鑰的建議長度，例如加密後的資料只想保存到西元2010年，如果使用對稱式加密法加密資料，則使用長度為80位元的金鑰就足夠了，但是如果是使用非對稱式加密法來加密資料，則必須使用長度至少為1024位元的金鑰。如果機密資料想保存到西元2030年，則使用對稱式加密法加密資料的話，建議使用長度為112位元的金鑰，而如果要使用非對稱式加密法加密資料的話，建議使用長度為2048位元的金鑰。
將密碼抄在紙上避免忘記，只要抄有密碼的紙條外洩，機密資料就曝光了，所以並不是很安全的做法，當然將帳號與密碼寫在紙上，再貼在電腦的螢幕上，避免忘記，雖然方便使用者登入系統，但是卻會造成資訊系統的身分驗証機制形同虛設，不是具備資訊安全概念的專業人士應有的行為。
正確答案：C
說明：
因為只給公司內部員工使用的網站仍然必須注意駭客攻擊的問題，因為攻擊網頁的駭客不一定都來自外界，也有可能來自公司內部的員工。另外應用程式與網頁要盡量使用權限較低的帳號登入資料庫，使用太高權限的帳號登入資料庫，如果網頁遭駭客利用，對網頁所使用的資料庫發起惡意攻擊，其對資料庫形成的破壞力也會最大。另外給公司內部員工使用的網頁如果不加上任何登入管制，形同允許使用者可以不經身分驗証檢查就使用網頁提供的功能，網頁將會亳無安全性可言。
正確答案：C
說明：
使用資料庫系統管理員或是Windows系統管理員的身分登入資料庫，然後進行資料庫操作，因為權限很高，所以存取資料庫不會碰到權限不足的狀況，雖然是很方便的做法，但是使用權限太高的帳號登入資料庫的應用程式或網頁一旦受到駭客所利用，對網頁所使用的資料庫進行破壞，對資料庫記錄產生的攻擊傷害也會比較嚴重。程式或網頁除了要盡量以較低權限的帳號登入資料庫以外，也要儘量以較低權限的帳號當做程式的執行身分，這樣做的好處是萬一程式或網頁被駭客所利用，對程式和網頁執行所在的電腦產生的破壞力也會比較低。
正確答案：D
說明：
網站的安全如果發生問題，不能只怪罪網站管理員，因為有超過半數的網站安全問題是因為設計網站的程式設計師在寫作程式時沒有注意要安全的問題所造成的，所以提升網站的安全性有賴於網站管理員，負責設計網站架構的系統架構師，以及負責設計網站程式的程式設計師三者共同的努力，三種角色都有不可推缷的責任。
正確答案：C
說明：
選擇帳號欲使用的密碼要盡量使用複雜密碼，也就是使用由英文字母，阿拉伯數字，以及特殊符號所組成的密碼，並限制密碼的最少長度，以達到較佳的安全性，因為複雜密碼不容易被駭客猜中，所以有助於提升資訊系統的安全性。採用和帳號完全相同的密碼，例如帳號為administrator或是Admin，密碼也就跟著使用administrator或是Admin，是很粗糙的做法，而且除了空白密碼之外，最容易被駭客猜中的密碼之一。當然使用空白密碼(即不指定密碼內容)，也是極度傷害資訊系統的安全性的做法，因為使用者如果可以不輸入密碼就進入到欲使用的資訊系統，代表系統未實作身分驗証機制，不旦棄守阻擋駭客攻擊的第一道防線，而且也會影響到系統依據使用者登入使用的帳號進行授與執行權限的安全管制功能。
◎科目：資料庫
要管理好SQL Server 2005的安全性設定，是一件非常不容易的事情，從登入帳戶的建立開始，就要區分使用Windows驗證與SQL Server
驗證等方式。SQL Server 2005中提供了許多安全性的功能，例如結構描述的設定、EXECUTE
AS更換執行階段的權限、憑證的建立、建立數位簽章等等多達數十種，針對這些功能的使用，該注意哪些事情與該如何應用，這些都是重點。
SQL Server
2005的安全性設定，需要有正確的觀念之後，運用起來才能得心應手，否則不正確的權限授與，情況輕者就是沒有給足夠權限，情況嚴重者就是給予過大的權限，導致整個資料庫環境暴露在危險的情況，藉由問答的形式，希望讓使用SQL
Server 2005的讀者有更深層的體會。
說明：
一般資料庫登入帳戶，如果需要透過陳述式關閉SQL SERVER 2005執行個體，需要具有SHUTDOWN的陳述式的執行權限。該陳述式預設是僅授與給系統管理員(SysAdmin)和伺服器管理員(ServerAdmin)固定伺服器角色，一般使用者無法可以藉由陳述式，直接關閉SQL Server 2005的執行個體。以下就是一般登入帳戶的成員，執行SHUTDOWN陳述式時，因為權限不足所產生的錯誤訊息。為了要模擬此問題，讀者可以在SQL Server 2005所在的機器中建立一個Windows使用者，例如W2003R2\ADA，該使用者僅是一般的Users群組，沒有特殊權限。接下來，在SQL Server 2005針對此Windows帳戶建立對應登入帳戶，過程中可以使用圖1的T-SQL語法，注意該登入帳戶沒有特殊權限與功能。
圖1：建立僅可以登入SQL Server 2005的Windows帳戶
接下來使用上述的Windows的帳戶登入SQL Server 2005之後，嘗試執行SHUWDOWN WITH NOWAIT的陳述式，就會產生圖2的錯誤。
圖2：因為權限不足無法關閉執行個體
如果要讓該使用者在沒有其他特殊權限的狀況，並且可以具有關閉執行個體的權限，可以使用SQL Server 2005的登入帳戶權限設定畫面，參考圖3的設定，就可以輕輕鬆鬆完成，並且也不會給予其他過大的權限。
圖3：設定給ADA帳戶有關必執行個體的權限
當完成上述的陳述式之後，登入帳戶ADA就可以再執行「SHUTDOWN WITH NOWAIT」陳述式，關閉執行個體。
說明：
新一代的SQL Server 2005在權限內容切換上面，都是藉由「EXECUTE AS」陳述式進行作業，該陳述式主要有以下的數種作用。
1. 切換個體階層的登入帳戶的權限內容，語法為「EXECUTE AS LOGIN」。
2. 切換資料庫階層的使用者帳戶的權限內容，語法為「EXECUTE AS USER」。
以下要介紹的是「EXECUTE AS LOGIN」的使用範例，該陳述式影響作業層級是整個執行個體的登入帳戶。此應用範例中將模擬登入帳戶為「mary」，經過利用「EXECUTE AS John」的方式，轉換以「John」的登入帳戶，進行執行個體階層資源的存取。
該範例就是先建立「mary」的登入帳戶，並且僅給一般「Connect SQL」的權限，但是「John」的登入帳戶確有「dbcreator」的固定伺服器角色的權限。接著利用「mary」登入之後，經過「EXECUTE AS LOGIN」進行登入帳戶轉換，使用「John」登入帳戶進行資料庫的管理作業。
--建立兩個SQL Server 驗證的登入帳戶
USE master
GO
CREATE LOGIN [mary] WITH PASSWORD='P@Ssw0rd'
GO
CREATE LOGIN [John] WITH PASSWORD='P@ssw0rd'
GO
--給予John登入帳戶擁有dbcreator的伺服器群組權限
EXEC sp_addsrvrolemember @loginame = N'John', @rolename = N'dbcreator'
GO執行登入帳號轉換之前，要有一個非常重要的設定，就是要將「John」在執行個體的權限設定給「mary」，主要就是指定「John」的「IMPERSONATE」的權限給「mary」。藉由這樣的設定之後，「mary」才有能力使用「John」在執行個體所擁有權限。其中，僅有一種例外是可以不用得到「John」的「IMPERSONATE」設定，就可以直接使用「John」的任何權限，就是當登入帳戶已經是sysadmin角色或是擁有CONTROL SERVER的執行個體權限，就可以省去此「IMPERSONATE」權限的授與。
--設定John的IMPERSONATE權限設定給mary，這個是非常重要的設定步驟
GRANT IMPERSONATE ON LOGIN::[John] TO [mary]
GO完成後「IMPERSONATE」權限設定後，接著使用「mary」的帳戶登入後進行測試，過程中先使用「mary」進行資料庫的建立。(圖4)
--使用mary進行登入執行個體的畫面
圖4：使用mary登入帳戶連接執行個體
--使mary帳戶嘗試執行建立資料庫
USE master
GO
--顯示當時的登入帳戶與使用者
SELECT SUSER_SNAME(),USER_NAME()
GO
--嘗試使用mary登入帳戶建立資料庫
CREATE DATABASE IMPDB
GO
--結果，因為mary沒有建立資料庫的權限，所以建立資料庫會發生失敗
------------------------------ ------------------------------
mary guest
(1 個資料列受到影響)
訊息 262，層級 14，狀態 1，行 1
於資料庫 'master' 中，CREATE DATABASE 的權限遭拒。接下來，利用「EXECUTE AS LOGIN」將連接狀態的權限內容，從「mary」的登入帳戶改成「John」的名稱，就可以藉由「John」的「dbcreator」的角色，進行資料庫的建立與管理，最後在執行完成之後，記得利用「revert」陳述式將工作階段的執行內容，還原到上一個登入者的狀態。
--利用EXECUTE AS LOGIN 的陳述式切換權限內容
USE master
EXECUTE AS LOGIN='John'; --切換成John的權限內容
--建立資料庫，可以成功
CREATE DATABASE IMPDB
GO
REVERT; --切換回原登入帳戶權限內容
說明：
憑證主要設計架構，是用在讓外部使用者，藉由公鑰進行作業再搭配對應的私鑰進行解密驗證，多運用在大量使用者登入的環境。過程中藉由憑證的驗證可以減少維護每個登入者的密碼作業。SQL Server 2005可以利用「CREATE CERTIFICATE」直接在資料庫端建立憑證，指定憑證名稱、加密密碼，過程中依照 X.509 標準定義所有憑證。以下的範例會先示範在資料庫中該如何建立憑證：
--建立憑證
USE AdventureWorks
CREATE CERTIFICATE certKey77 --建立的憑證名稱
ENCRYPTION BY PASSWORD = 'P@ssw0rd' --憑證加密的密碼
WITH SUBJECT = 'Credit Card Certificate', --憑證主旨
START_DATE ='2007/01/01', --憑證生效的日期
EXPIRY_DATE = '2007/12/31'; --憑證到期的日期
GO接下來，如果要使用憑證進行資料庫預存程序、使用者自訂函數、觸發程序等的註記數位簽章作業，則可以利用ADD SIGNATURE陳述式，搭配憑證的使用完成。這樣的用意可以用使用憑證登入的帳戶，指定存取已經完成註記簽章的物件。
此外，如果該預存程序有經過修改之後，該簽章的部分就會自動移除，藉此表示該預存程序已經遭受到修改或破壞，這樣可以避免存取不正確的資料庫物件。以下示範使用憑證，進行資料庫預存程序註記數位簽章。(圖5)
--使用憑證進行預存程序的註記簽章作業
USE AdventureWorks
GO
ADD SIGNATURE TO dbo.uspGetBillOfMaterials
BY CERTIFICATE certKey77
WITH PASSWORD = 'P@ssw0rd'
GO圖5：檢視經過憑證簽章處理過的預存程序
說明：
新一代的SQL Server 2005提供動態管理檢視與系統預存程序，讓資料庫管理員查詢任何前端連結的資訊。這些系統目錄檢視或是系統物件，所提供的資訊非常豐富，包括前端應用程式的名稱、連線資訊、最後執行指令等等，以下將使用最簡單的方式給讀者快速抓取前端連結的訊息，例如IP位址、電腦名稱等，達成安全性管理的監控效果。(圖6)
--使用sys.dm_exec_connections查詢本執行階段的IP位置
SELECT client_net_address 'Client IP Address',
local_net_address 'SQL Server IP Address',*
FROM sys.dm_exec_connections
WHERE session_id=@@SPID
GO
--搭配前端應用程式更可以突顯這個系統物件提供的效果圖6：使用前端應用程式抓取sys.dm_exec_connections資訊
說明：
在SQL Server 2005的系統之中，有一個特殊登入帳戶名稱為「sa」，該帳戶就是對等SYSADMIN的伺服器角色群組權限，當使用「sa」就會對應到各個資料庫之中dbo的使用者。因此當應用程式使用sa的登入帳戶，進行連結後端SQL Server 2005之後，就可能發生很多安全性漏洞的疑慮。因此以下有幾種作法可以保護sa帳戶，例如變更該帳戶名稱或是停用該帳戶。如果需要變更原本的sa登入帳戶的名稱或是停用該帳戶，來防止接受一般前端應用程式使用，可以參考以下的範例。
--停用前端應用程式使用sa的帳戶
ALTER LOGIN [sa] DISABLE;
GO
--將sa變更新的名稱
ALTER LOGIN [sa] WITH NAME = [newAdmin];
GO此外要提醒各位讀者，有關修改sa登入帳戶的後續相關問題，雖然sa可以修改名稱，但是在背景程式例如LOCK MONITOR、LOG WRITER、TASK MANAGER等等，依然不會受到sa變更名稱的影響。以下就是變更sa名稱之後，使用系統物件查詢依然使用sa的程式狀況。(圖7)
--查詢變更sa之後，仍然使用sa的應用程式
SELECT loginame,status,cmd,*
FROM master.sys.sysprocesses
--結果圖7：利用系統物件檢查使用SA的所有程式
說明：
剛安裝完成的SQL Server 2005僅提供Windows驗證的登入方式，如果從其他非網域的方式，使用SQL Server驗證進行連結SQL Server 2005，就會出現圖8的錯誤訊息。
圖8：發生無法使用SQL Server驗證登入錯誤訊息
當發生圖8的錯誤畫面的時候，讀者可以執行以下幾個步驟，進行整體登入權限檢查作業。首先要確認該SQL Server 2005是否已經開啟TCP/IP或Named Pipe等通訊協定的設定，該檢查作業可以使用「SQL Server Configuration Manager」程式進行檢查(圖9)，此外還需要使用SQL Server Management Studio檢查SQL Server 2005的執行個體，是否開啟SQL Server及Windows驗證模式，圖10就是可能需要檢查的畫面設定。
圖9：檢查是否有開啟相關的通訊協定
圖10：檢查執行個體是否已經開啟SQL Server與Windows驗證模式
Copyright© FLAG INFORMATION CO., LTD. 旗訊科技(股)公司. All rights reserved. 本站圖文著作權所有 未經授權 不得任意轉載使用