2024年7月30日 星期二

[研究]SQL Server 2022安裝後,Windows Server 2022 的 hostname,對 SQL Server 的影響?

[研究]SQL Server 2022安裝後,Windows Server 2022 的 hostname,對 SQL Server 的影響?

2024-07-30

Windows Server 2022 +SQL Server 2022 + SSMS 安裝完後,Windows 變更 hostname,對 SQL Server 或 SSMS 的影響?

ChatGPT

變更 Windows hostname 後,對 SQL Server 和 SSMS 可能會有以下影響:

  1. SQL Server 設定:SQL Server 的服務會繼續運行,但一些內部設定(例如登記名稱)可能仍會使用舊的 hostname。這可能會導致一些內部連接和管理工具出現問題。
  2. 連接字符串:如果應用程式或用戶連接到 SQL Server 的連接字符串中使用了舊的 hostname,那麼這些連接會失效,必須更新為新的 hostname。
  3. SQL Server 代理作業:一些 SQL Server 代理作業可能會依賴於 hostname,這些作業也需要檢查並更新相關設定。
  4. SSMS 連接:在 SSMS 中,如果之前使用舊的 hostname 進行連接,那麼這些連接也需要更新為新的 hostname。

要確保系統正常運行並更新所有相關設定,可以參考以下步驟:

【更新 SQL Server 設定】

1.檢查 SQL Server 名稱:


SELECT @@SERVERNAME;

2.更新 SQL Server 名稱:

EXEC sp_dropserver '舊的_hostname';

EXEC sp_addserver '新的_hostname', 'local';


3.重啟 SQL Server 服務:確保更改生效。

更新連接字符串】

更新應用程式或用戶連接到 SQL Server 的連接字符串,使其使用新的 hostname。

檢查 SQL Server 代理作業】

檢查並更新所有 SQL Server 代理作業中可能使用舊 hostname 的部分。

更新 SSMS 連接】

在 SSMS 中,刪除舊的連接配置,使用新的 hostname 創建新的連接。

這些步驟應該能確保 SQL Server 和 SSMS 在更改 hostname 後能正常運行。如果在更新過程中遇到任何問題,可以查閱官方文件或尋求專業支援。

【影響版本】

從 SQL Server 2008 開始,變更主機名會影響 SQL Server,這是由於 SQL Server 的內部配置會依賴於安裝時的主機名。需要手動更新這些配置以確保系統正常運行。

對於 SQL Server 2005 和更早的版本,變更主機名也會有類似的影響,但處理方法和步驟可能會有所不同,因此建議參考相應版本的官方文件。

********************************************************************************












(完)

相關

[研究][SQL Server 2017]伺服器層級的 Urn 篩選無效;變更 SQL Server 的 ServerName
https://shaurong.blogspot.com/2018/10/sql-server-2017-urn.html


[研究]SQL Server 2019 RTM CU (KB5040948) 安裝過程出現 0x8024000b 錯誤

[研究]SQL Server 2019 RTM CU (KB5040948) 安裝過程出現 0x8024000b 錯誤

2024-07-29

Windows Server 2019 + SQL Server 2019 的 Windows Update 的 SQL Server 2019 RTM CU (KB5040948) 安裝過程出現 0x8024000b 錯誤




********************************************************************************
Windows Server 2019 + SQL Server 2019 的 Windows Update 的 SQL Server 2019 RTM CU (KB5040948) 安裝過程出現 0x8024000b 錯誤?

ChatGPT

錯誤代碼 0x8024000b 在安裝 Windows 更新時通常表示更新包中的某些簽名或憑證無法驗證。對於 SQL Server 2019 RTM CU (KB5040948) 的安裝過程出現此錯誤,可以嘗試以下幾個步驟來解決問題:

1.重啟系統:有時候重啟系統可以解決臨時的問題。

2.手動下載並安裝更新:從 Microsoft 官方網站手動下載該更新,然後嘗試手動安裝。

適用於 Microsoft Windows 的 SQL Server 2019 最新累積更新

SQL Server 2019 for Microsoft Windows Latest Cumulative Update

3.清理 Windows 更新緩存:
有時候,Windows 更新緩存中的文件可能會導致問題。可以嘗試清理緩存。

打開命令提示符(以管理員身份運行)。

輸入以下命令並按回車:

net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserver
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 Catroot2.old
net start wuauserv
net start cryptSvc
net start bits
net start msiserver

這些命令將停止 Windows 更新相關的服務,重命名緩存文件夾,並重新啟動服務。

4.檢查系統時間和日期:確保系統時間和日期是正確的。如果時間和日期不正確,可能會導致更新簽名無法驗證。

5.使用 Windows 更新疑難解答工具:Windows 內置的更新疑難解答工具可以幫助檢查並修復常見的更新問題。
  • 打開設定 (Settings)。
  • 轉到更新和安全 (Update & Security)。
  • 點擊疑難解答 (Troubleshoot)。
  • 選擇 Windows 更新 (Windows Update) 並運行疑難解答工具。
註:
[研究]Windows Server 2019「疑難排解」功能試用
https://shaurong.blogspot.com/2024/07/windows-server-2019.html

如果以上步驟仍然無法解決問題,建議查看 Windows 事件查看器中的具體錯誤信息,或者檢查 SQL Server 的安裝日誌文件以獲取更多詳細信息。這樣可以更精確地診斷問題並尋找解決方案。


********************************************************************************

WU_E_CALL_CANCELLED 作業已取消。 用戶或服務已取消作業。 當我們無法篩選結果時,您也可能會收到此錯誤。

********************************************************************************

總結:後來用「3.清理 Windows 更新緩存」,然後重新啟動 Windows,再次 Windows Update,解決了。





(完)

相關

[研究]Windows Server 2019「疑難排解」功能試用
https://shaurong.blogspot.com/2024/07/windows-server-2019.html


[研究]Windows Server 2019「疑難排解」功能試用

[研究]Windows Server 2019「疑難排解」功能試用

2024-07-30

Windows 內置的更新疑難解答工具可以幫助檢查並修復常見的更新問題。

  1. 打開設定 (Settings)。
  2. 轉到更新和安全 (Update & Security)。
  3. 點擊疑難解答 (Troubleshoot)。
  4. 選擇 Windows 更新 (Windows Update) 並運行疑難解答工具。

****************************************

敝人嘗試解決:SQL Server 2019 RTM CU (KB5040948) 安裝過程出現 0x8024000b 錯誤

畫面如下
















「疑難排解」功能不是萬能的,本問題仍解決失敗。

(完)

2024年7月26日 星期五

[研究]Windows Server 2022忘記密碼處理

[研究]Windows Server 2022忘記密碼處理

2024-07-26

忘記 Windows Server 2022 所有管理員密碼,如何用 Windows Server 2022 Bootable Installable USB  Flash 重設 administrator 密碼  ?

Power On電腦開機時,快速多按下幾次F8按鍵。

1.進入修復模式:

當安裝程序啟動時,選擇您的語言設置,然後點擊「下一步」。

點擊左下角的「修復您的電腦」,選擇「疑難解答」 > 「命令提示字元」。

更改 utilman.exe 為 cmd.exe:

在命令提示符中輸入以下命令,進入 Windows 安裝目錄:

cd /d D:\Windows\System32

如果 D: 不是您的 Windows 安裝分區,請根據需要調整。(可能是 C: 或 D: 或 E:,找有 utilman.exe 和 cmd.exe 檔案的)


2.將 utilman.exe 更名為備份文件:

ren utilman.exe utilman.exe.bak

將 cmd.exe 複製並重命名為 utilman.exe:

copy cmd.exe utilman.exe

重啟到正常模式:

關閉命令提示符並選擇「繼續」以重新啟動到 Windows。


3.重設密碼:

在登錄屏幕上,點擊「輔助工具」圖標(應該打開命令提示符)。

在命令提示符中輸入以下命令來重設管理員密碼:

net user administrator 新密碼


4.恢復 utilman.exe:

cd /d D:\Windows\System32

del utilman.exe

ren utilman.exe.bak utilman.exe

這樣您就可以重置 Windows Server 2022 的管理員密碼了。

********************************************************************************

實務上可能略有不同,例如

ren utilman.exe.old utilman.exe 出現 "存取被拒。"

變通一下

copy utilman.exe.old utilman.exe 成功。


一開始要改的在 E:,改好重啟後,utilman.exe 和 cmd.exe 是在 C:









Windows Server 2016、Windows Server 2019、Windows Server 2022 都是 NT 10.0,方法可能相同。

(完)

2024年7月19日 星期五

[研究]Windows Server 2019 有哪些 Windows 群組 可以檢視 Windows Event Log

[研究]Windows Server 2019 有哪些 Windows 群組 可以檢視 Windows Event Log 

2024-07-19

下面 Windows Server 2019 有哪些 Windows 群組 可以檢視 Windows Event Log ?

  • Access Control Assistance Operators
  • Administrators
  • Backup Operators
  • Certifificate Service DCOM Access
  • Cryptographic Operators
  • Device Owners
  • Distributed COM Users
  • Event Log Readers
  • Guests
  • Hyper-VAdmiministrators
  • IIS_JUSRS
  • Network Configuration Operatorators
  • Performance Log Users
  • Performance Monitor Users
  • Power Users
  • Print Operators
  • RDS Endpoint Servers
  • RDS Management Servers
  • RDS Remote Access Servers
  • Remote Desktop Users
  • Remote Management Users
  • Replicator
  • Storage Replica Administrators
  • System Managed Accounts Group
  • Users


ChatGPT

在 Windows Server 2019 中,以下群組擁有檢視 Windows Event Log 的權限:

  • Administrators - 擁有完全的系統管理權限,包括檢視和管理事件日誌。
  • Event Log Readers - 專門設計來檢視事件日誌的群組。
  • Backup Operators - 雖然主要用於備份和恢復,但也有檢視事件日誌的權限。
  • Performance Log Users - 可以讀取性能日誌,但通常也有檢視事件日誌的權限。
  • Performance Monitor Users - 擁有檢視性能相關事件的權限,也能檢視事件日誌。

其他群組,如 Remote Desktop Users 或 Network Configuration Operators,通常沒有預設檢視事件日誌的權限。

(完)

[研究]能設定 Sesssion Time Out 為無限大或關閉嗎?

[研究]能設定 Sesssion Time Out 為無限大或關閉嗎?

2024-07-19

環境:Visual Studio 2022 + ASP.NET + WebForm + Web Application + C# + SQL Server 2019 + SQL Server Management Studio (SSMS) 19

********************************************************************************

ASP.NET  WebForm 能設定 Sesssion Time Out 為無限大或關閉嗎?

ChatGPT

在 ASP.NET WebForms 中,Session 的超時設置是無法設置為無限大或完全關閉的。然而,您可以將超時設置為非常長的時間,以便實際使用中接近無限大。這是透過在 web.config 文件中修改 sessionState 元素來實現的。例如:

<configuration>
  <system.web>
    <sessionState timeout="525600" />
  </system.web>
</configuration>

上述配置將 Session 的超時設置為 525600 分鐘,即一年。這已經是一個相當長的時間,但仍然不是無限大。

另外一點需要注意的是,這樣設置並不一定是最佳實踐,因為長時間的 Session 會佔用更多的服務器資源,並且可能會導致其他潛在的性能和安全問題。一般來說,最好根據應用程序的需求來設置適當的 Session 超時時間,並且在必要時通過其他機制(例如,持久性存儲)來保存用戶狀態。

********************************************************************************

IIS  能設定 Sesssion Time Out 為無限大或關閉嗎?

ChatGPT

在 IIS (Internet Information Services) 中,也無法將 Session 超時設置為無限大或完全關閉。但同樣地,您可以設置一個非常長的超時時間。

在 IIS 中,Session 超時設置是通過應用程序池的閒置超時設置來控制的。雖然您無法將其設置為無限大,但可以將其設置為非常大的數值。以下是如何在 IIS 中修改應用程序池的閒置超時設置:

  1. 打開 IIS 管理器:按下 Win + R 鍵,輸入 inetmgr,然後按下 Enter 鍵。
  2. 選擇您的應用程序池:在左側面板中展開 本地計算機,選擇 應用程式池。
  3. 修改應用程序池設置:在中間面板中選擇您的應用程序池,然後在右側面板中點擊 進階設定。
  4. 修改閒置超時(Idle Time-out)設置:在彈出的對話框中找到 閒置超時(分鐘)(Idle Time-out (minutes))設置,將其值設置為所需的分鐘數。例如,將其設置為 525600 分鐘,即一年。

儘管如此,這個設置還是有其限制和風險。長時間保持閒置的 Session 會佔用更多的服務器資源,並可能引起性能問題。因此,應該根據應用程序的具體需求進行設置,並考慮使用其他方式來保存用戶狀態,如持久化存儲。

總結來說,無論是在 ASP.NET WebForms 還是 IIS 中,都無法將 Session 超時設置為無限大或完全關閉,但可以設置為非常長的時間。

********************************************************************************

tomcat 能設定 Sesssion Time Out 為無限大或關閉嗎?

ChatGPT

在 Apache Tomcat 中,您無法將 Session 超時設置為無限大或完全關閉,但您可以將其設置為非常長的時間。

在 Tomcat 中,Session 超時時間是通過 web.xml 文件中的 <session-config> 元素進行配置的。您可以將 Session 超時設置為非常大的數值來接近無限大。以下是如何進行配置的示例:

  1. 打開您的 web.xml 文件,該文件通常位於您的 Web 應用程序的 WEB-INF 目錄中。
  2. 添加或修改 <session-config> 元素來設置超時時間。例如:

<web-app>
  ...
  <session-config>
    <session-timeout>525600</session-timeout> <!-- 這裡設置為一年(以分鐘計) -->
  </session-config>
  ...
</web-app>

這樣設置將 Session 的超時時間設置為 525600 分鐘,即一年。

同樣地,這種設置並不一定是最佳實踐,因為長時間的 Session 會佔用更多的服務器資源,並可能導致其他潛在的性能和安全問題。最好根據應用程序的需求來設置適當的 Session 超時時間,並且在必要時通過其他機制(例如,持久性存儲)來保存用戶狀態。

總結來說,在 Tomcat 中,無法將 Session 超時設置為無限大或完全關閉,但可以設置為非常長的時間。

********************************************************************************

apache httpd web server 能設定 Sesssion Time Out 為無限大或關閉嗎?

ChatGPT

在 Apache HTTPD Web 伺服器中,設定 Session Timeout 為無限大或關閉並不完全可能,因為這通常是由應用程式層級的設定來控制的,而不是直接由 Apache HTTPD 設定的。

不過,你可以通過調整相關的 Apache 模組設定來影響 Session 行為。以下是一些相關的設定:

1.mod_session 模組: 如果你使用 mod_session 模組來管理 Session,你可以通過設定 SessionTimeout 來調整超時時間。設定為一個非常大的值來實現長時間的 Session。例如:

<IfModule mod_session.c>
    SessionTimeout 31536000
</IfModule>

這裡 31536000 是一年的秒數。

2.mod_auth_cookie 模組: 如果你使用 mod_auth_cookie 來處理 Cookie 的 Session,你可以通過設定 SessionCookieTimeout 來控制 Cookie 的有效期。例如:

<IfModule mod_auth_cookie.c>
    SessionCookieTimeout 31536000
</IfModule>

應用程式層級設定: 如果你使用的是 PHP、Python 或其他語言編寫的應用程式,Session Timeout 的設定通常在應用程式的配置文件中進行。例如,在 PHP 中,你可以在 php.ini 文件中設置 session.gc_maxlifetime 來延長 Session 的有效時間:

<IfModule mod_auth_cookie.c>
    SessionCookieTimeout 31536000
</IfModule>

需要注意的是,將 Session Timeout 設置為非常長的時間或者無限大可能會帶來安全風險,如 Session 劫持。建議根據應用程式的需求和安全考量來設定適當的 Session 超時時間。

********************************************************************************

PHP 能設定 Sesssion Time Out 為無限大或關閉嗎?

ChatGPT

在 PHP 中,將 Session Timeout 設定為「無限大」或「關閉」並不完全可行,但你可以將其設置為一個非常大的值來實現接近無限的效果。這樣的設置會使 Session 在實際使用中不會過期,但仍然會受到 PHP 的垃圾回收機制影響。以下是一些相關的設定:

1、session.gc_maxlifetime: 這個設定定義了 Session 在沒有活動的情況下被回收前的最大時間(以秒為單位)。你可以將其設置為非常大的值來實現長時間不過期的效果,例如一年的秒數(31536000秒):


session.gc_maxlifetime = 31536000  

 

2、session.cookie_lifetime: 這個設定定義了 Session Cookie 的有效期(以秒為單位)。如果你希望 Session Cookie 在瀏覽器關閉後不失效,你可以將其設置為一個非常大的值:.

session.cookie_lifetime = 31536000 

3、session.use_cookies 和 session.use_only_cookies: 確保這些設置是開啟的,以便 Session 通過 Cookie 存儲:.

session.use_cookies = 1

session.use_only_cookies = 1  

4、session.gc_probability 和 session.gc_divisor: 這些設定控制垃圾回收機制的機率。可以調整這些設定來影響 Session 的清理頻率。默認值是 gc_probability = 1 和 gc_divisor = 100,意味著每 100 次請求中 1 次會進行垃圾回收。

session.gc_probability = 1   

session.gc_divisor = 100

雖然這些設置可以延長 Session 的有效時間,但完全關閉 Session 超時仍然是不現實的,並且這樣做會帶來潛在的安全風險,如 Session 劫持或資源泄漏。建議根據實際需要來設定合理的超時時間,並定期進行安全性檢查。

********************************************************************************

JSP 能設定 Sesssion Time Out 為無限大或關閉嗎?

ChatGPT

在 JSP (JavaServer Pages) 中,Session Timeout 的設定可以通過 Web 應用程式的 web.xml 文件來進行。雖然不能完全將 Session Timeout 設置為無限大或關閉,但你可以將其設置為非常大的值來實現長時間不過期的效果。

以下是一些設定步驟:

1、設定 Session Timeout:

在 web.xml 文件中,你可以設定 <session-config> 元素來定義 Session 的超時時間。這裡的時間以分鐘為單位。例如,設置為一年的秒數(525600分鐘):

<session-config>
    <session-timeout>525600</session-timeout> <!-- 一年的分鐘數 -->
</session-config>

這樣設置後,Session 將在 525600 分鐘(即 1 年)內不會自動過期。

2、在應用程式中控制 Session Timeout:

如果你需要在應用程式層級動態調整 Session 的超時時間,可以在 JSP 或 Servlet 中使用以下代碼:.

HttpSession session = request.getSession();
session.setMaxInactiveInterval(31536000); // 設置為一年(秒數)  

setMaxInactiveInterval 方法接受的參數是秒數。這樣設置後,Session 的超時時間將會是 31536000 秒(即 1 年)。

3、注意安全風險:

將 Session Timeout 設置為非常長的時間或無限大可能會導致安全問題,例如 Session 劫持或其他安全風險。建議根據實際需求和安全考量來設定合理的 Session 超時時間,並定期檢查和更新安全策略。

總之,雖然你不能完全關閉 Session Timeout,但可以將其設置為非常大的值來達到類似的效果。

********************************************************************************

(完)

相關

[研究]GCB的Chrome規則:不論線上OCSP/CRL檢查是否執行

[研究]GCB的Chrome規則:不論線上OCSP/CRL檢查是否執行

2024-07-18 

不論線上OCSP/CRL檢查是否執行

說明:

由於線上撤銷檢查(監測隨機性軟體錯誤)無法提供實際的安全性效效益,因此在 Google Chrome 版本 19 和更新的版本中,系統已預設停用這些檢查。將這項政策設定為True,系統會還原先前行為,並且會執行線上OCSP/CRL 檢查ㆍ

如未設定這項政策,或將政策設定為False,則GoogleChrome 不會在Google Chrome 19 和更新版本中執行線上撤销検查。

********************************************************************************

何謂 OCSP/CRL 檢查 ?

ChatGPT

OCSP(Online Certificate Status Protocol)和 CRL(Certificate Revocation List)是用來驗證數位憑證狀態的兩種方法。

OCSP (Online Certificate Status Protocol)

OCSP 是一種即時查詢數位憑證狀態的協議,主要特點如下:

  • 即時查詢:用戶端可以向 OCSP 伺服器發出請求,詢問某個憑證是否被撤銷。
  • 回應速度快:因為 OCSP 只需查詢單個憑證的狀態,所以相對快速。
  • 減少網絡負擔:OCSP 的查詢和回應資料量較小。

CRL (Certificate Revocation List)

CRL 是一種包含已被撤銷憑證列表的檔案,主要特點如下:

  • 定期更新:CA(憑證授權機構)定期發布 CRL 文件,列出所有被撤銷的憑證。
  • 下載完整列表:用戶端需要下載整個 CRL 檔案來檢查某個憑證是否在撤銷列表中。
  • 較大文件:隨著時間推移,CRL 文件可能會變得很大,導致下載和處理速度變慢。

比較

  • 查詢速度:OCSP 更快,因為它只查詢單個憑證的狀態,而 CRL 需要下載並檢查整個列表。
  • 網絡流量:OCSP 生成的流量較小,而 CRL 可能產生較大流量,特別是在 CRL 文件很大的情況下。
  • 實時性:OCSP 可以即時提供憑證狀態資訊,而 CRL 則依賴於定期更新,因此可能不夠即時。

這兩種方法各有優缺點,具體選擇取決於應用場景和需求。

********************************************************************************

請問為何 OCSP/CRL 檢查 啟用後,

相同網段上,經過相同的防火牆連上 Internet,

Chrome 或 Edge 瀏覽器走 HTTPS 連網站正常;

Chrome 瀏覽器走 HTTPS 但 port 不是 443 連網站失敗;

Edge 瀏覽器走 HTTPS 但 port 不是 443 連網站仍可成功;

ChatGPT

這種現象可能是由於瀏覽器之間處理 OCSP/CRL 檢查和非標準 HTTPS 埠的方式不同所導致的。以下是一些可能的原因和解釋:

1. 瀏覽器處理方式不同

Chrome 瀏覽器在進行 OCSP/CRL 檢查時,可能嚴格要求使用標準 HTTPS 埠(443)。當連接使用非標準埠時,Chrome 可能會因無法正確完成 OCSP/CRL 檢查而阻止連接。

Edge 瀏覽器可能對非標準埠的處理較為靈活,允許在非標準埠上進行 OCSP/CRL 檢查,即使在非標準埠上也能成功完成憑證驗證,因此可以正常連接。

2. 瀏覽器的安全策略

Chrome 瀏覽器的安全策略可能更為嚴格,當使用非標準埠時,如果 OCSP/CRL 檢查遇到問題,它可能會直接阻止連接,視為不安全連接。

Edge 瀏覽器可能有不同的安全策略,允許更多的彈性,特別是在處理非標準埠的 HTTPS 連接時。

3. 設定和實作差異

Chrome 瀏覽器可能在其網絡堆疊中對非標準埠的支持有限,特別是在進行安全檢查和驗證時。

Edge 瀏覽器可能在其設計和實作上對非標準埠的處理更為完善,能夠正確處理 OCSP/CRL 檢查,即使是非標準埠。

4. 瀏覽器更新和版本差異

********************************************************************************
請問為何 OCSP/CRL 檢查 啟用後,
相同網段上,經過相同的防火牆連上 Internet,
Chrome 或 Edge 瀏覽器走 HTTPS 連網站正常;
Chrome 瀏覽器走 HTTPS 但 port 不是 443 連網站失敗;
Edge 瀏覽器走 HTTPS 但 port 不是 443 連網站仍可成功;

ChatGPT

這個情況可能涉及到不同瀏覽器在處理 HTTPS 連線時的一些差異性,特別是在遇到非標準端口(非 443)時的行為可能會有所不同。這裡有幾點可能的原因:

  1. 瀏覽器對非標準 HTTPS 端口的支援不同:一些瀏覽器對於 HTTPS 連線的標準可能有較嚴格的要求,如果不是預設的 443 端口,可能會有特定的處理方式或安全檢查。
  2. 防火牆或代理伺服器設定不同:不同的瀏覽器可能會使用不同的網路堆疊或代理設定。某些防火牆或代理伺服器可能會限制或影響非標準 HTTPS 端口的連線,這可能導致某些瀏覽器無法成功建立連線。
  3. OCSP/CRL 檢查的實作差異:在啟用 OCSP(Online Certificate Status Protocol)或 CRL(Certificate Revocation List)檢查後,不同瀏覽器可能會有不同的實作方式,導致其對於非標準 HTTPS 端口的支援表現不同。

解決這個問題的方法可能需要更深入的網路分析和瀏覽器設定的檢查。你可以進一步探索以下方向:
  1. 瀏覽器設定檢查:確保每個瀏覽器的安全設定和代理設定都是一致的。
  2. 網路分析工具:使用網路封包分析工具(如Wireshark)來觀察瀏覽器在連線時的確切行為和網路交互情況。
  3. 代理設定檢查:確認防火牆或代理伺服器的設定是否對所有瀏覽器都進行了相同的過濾或檢查,特別是對非標準 HTTPS 端口的處理。

********************************************************************************

(完)

2024年7月17日 星期三

[研究]產品生命周期各階段EOS、EOL、EOST、EOSL、EOM、EOE、EOA、EOSP、LTS、GA

[研究]產品生命周期各階段EOS、EOL、EOST、EOSL、EOM、EOE、EOA、EOSP、LTS、GA 

2024-07-17

有些縮寫可能完整英文不同。

ChatGPT

產品生命周期的各個階段可以依照它們通常出現的順序排列如下:

  1. GA (General Availability):全面上市,指產品正式對外發布,開始廣泛供應和銷售。
  2. LTS (Long Term Support):長期支持,指產品在較長時間內提供支持和維護更新,通常適用於軟件或操作系統。
  3. EOA (End of Availability):供應終止,指產品不再在市場上供應,可能已停止生產和銷售。
  4. EOS (End of Sale):停止銷售,指產品不再進行銷售。達到這一階段的產品將不再在市場上供應,但現有用戶可能仍會收到支持和維護服務,直到其他生命周期階段(如 EOL 或 EOSL)為止。
  5. EOL (End of Life):生命終止,指產品或技術不再進行任何更新、改進或支持,並可能被市場淘汰。
  6. EOE (End of Engineering):工程終止,指產品不再進行任何工程開發或改進。
  7. EOM (End of Maintenance):維護終止,指產品不再提供任何維護更新,包括修復補丁和安全更新。
  8. EOSP (End of Support):支持終止,指產品不再提供任何形式的支持,包括技術支持和客服支持。
  9. EOST (End of Support):支持終止,指產品不再提供任何形式的支持,包括技術支持、維護更新和修復服務。
  10. EOST (End of Service Transition):服務轉換終止,指產品或服務從現有支持轉換到終止支持階段的過渡期結束。
  11. EOS (End of Service):服務終止,指產品或服務不再提供任何形式的技術支持和維護服務。
  12. EOSL (End of Service Life):服務生命終止,指產品的服務支持完全終止,通常包括技術支持、修復和維護等。
  13. EOSL (End of Service/Support):服務生命終止,指產品的服務支持完全終止,這包括技術支持、維護更新和修復服務等。達到這一階段的產品將不再收到任何形式的支持,通常意味著客戶需要升級或更換產品以確保持續的支持和安全性。

這個順序反映了產品從市場推出到最終完全終止支持的完整生命周期。


註:在 EOL 階段,製造商可能仍會提供維護選項,但價格較高。EOS、EOSL 是指製造商停止銷售設備,且在大多數情況下在特定日期後不再提供維修服務或更新。

********************

其他

  • EOR (End of Renewal):續約終止,指產品或服務不再接受續約,現有合約到期後不再延續。
  • EOSS (End of Standard Support):標準支持終止,指標準支持服務終止,通常意味着將轉向延伸支持或客戶需升級產品。
  • EOSC (End of Service Contract):服務合約終止,指與客戶簽訂的服務合約終止,合約期結束後不再提供支持和服務。
  • EOLT (End of License Term):許可期限終止,指軟件許可證的有效期結束,不再提供使用權和相關服務。
  • EoU (End of Update):更新終止,指產品不再提供任何形式的更新,包括功能更新和安全補丁。
  • EDL (End of Development Life):開發生命終止,指產品不再進行任何開發,包括新特性和改進。
  • SLA (Service Level Agreement):服務水平協議,客戶和服務提供商之間的合約,規定了服務標準和支持級別。
  • M&S (Maintenance and Support):維護和支持,持續提供的維護和支持服務,通常包括修復、更新和技術支持。
  • N-1 Support:N-1 支持,支持當前版本以及前一個版本的策略,通常用於軟件和操作系統。
  • RTM (Release to Manufacturing):發佈到製造,軟件或硬件版本已完成測試,並準備進行大規模生產和發佈。


(完)

[研究]崩潰報告

[研究]崩潰報告

2024-07-16

Windows Server 2019 Standard 突然看到畫面


崩潰報告

對不起,因為發生了錯誤,終程序運行。

舉報錯誤,可就更容易解決問題。

錯誤發生的情況和現像

如果你記述錯誤發生的情況和現像、可豫料到的原因,可就更容易解決問題。

發送 關閉



(下圖) CrystalDiskInfo 9.2.1 測試

(完)

2024年7月16日 星期二

[研究] Opentext / Micro Focus Fortify SCA 產品生命週期、EOS、EOL

[研究] Opentext / Micro Focus Fortify SCA 產品生命週期、EOS、EOL

2024-07-16

Opentext Product Support Lifecycle (Opentext 產品生命週期)

https://www.microfocus.com/productlifecycle/

Fortify Static Code Analyzer 產品生命週期、EOS : End of Service、EOL : End of Life


(完)

[研究]系統 Windows Update 和 Windows Reboot,需要公告嗎?根據 ISO 27001 或 ISO 27002 哪一條?

[研究]系統 Windows Update 和 Windows Reboot,需要公告嗎?根據 ISO 27001 或 ISO 27002 哪一條?

2024-07-16

系統 Windows Update 後 Windows Reboot,需要公告嗎?根據 ISO 27001 或 ISO 27002 哪一條?

ChatGPT

根據 ISO 27001 和 ISO 27002 的要求,Windows Update 導致的 Windows Reboot 通知屬於資訊安全管理的一部分。特別是,這些標準強調應確保資訊系統的可用性和減少服務中斷的影響。

ISO 27001

ISO 27001 是一個資訊安全管理系統 (ISMS) 的標準,涵蓋了風險管理和資訊安全控制的要求。雖然標準本身並沒有具體指出每一種情況的具體操作,但以下條款是相關的:

  • A.12.1.1(作業程序文件化): 組織應建立和維護與資訊處理設施和系統相關的作業程序,包括系統更新和重新啟動的程序。(不是這樣,正確見下方英文原文)
  • A.12.4.1(事件報告): 應建立和維護資訊安全事件報告程序,包括系統重啟可能影響服務可用性時的通知程序。(不是這樣,正確見下方英文原文)

ISO 27002

ISO 27002 是 ISO 27001 的實踐指南,提供了具體的控制措施和實施指導:

  • 12.1.1(運營程序文檔): 強調了運營程序應該被文件化和傳達,包括系統更新和重新啟動的操作。
  • 12.4.2(事件通報): 應該有機制通知受影響的相關方,這包括在系統更新或重新啟動前通知用戶以避免服務中斷。

因此,根據 ISO 27001 和 ISO 27002 的最佳實踐,當 Windows Update 需要系統重新啟動時,應該通知所有相關用戶。這樣可以確保透明度並減少潛在的服務中斷對業務運行的影響。


********************************************************************************

ISO/IEC 27001:2013(E)

A.12.1.1 Documented operating procedures
Control
Operating procedures shall be documented and made available to all users who need them.

A.12.4.1 Event logging
Control
Event logs recording user activities, exceptions, faults and infor mation security events shall be produced, kept and regularly reviewed.

********************************************************************************

ISO/IEC 27002:2013(E)


2.1.1 Documented operating procedures

Control

Operating procedures should be documented and made available to all users who need them.


Implementation guidance

Documented procedures should be prepared for operational activities associated with information processing and communication facilities, such as computer start-up and close-down procedures, backup, equipment maintenance, media handling, computer room and mail handling management and safety.

The operating procedures should specify the operational instructions, including:

a) the installation and configuration of systems;

b) processing and handling of information both automated and manual;

c) backup (see 12.3);

d) scheduling requirements, including interdependencies with other systems, earliest job start and latest job completion times;

e) instructions for handling errors or other exceptional conditions, which might arise during job execution, including restrictions on the use of system utilities (see 9.4.4);

f) support and escalation contacts including external support contacts in the event of unexpected operational or technical difficulties;

g) special output and media handling instructions, such as the use of special stationery or the management of confidential output including procedures for secure disposal of output from failed 

jobs (see 8.3 and 11.2.7);

h) system restart and recovery procedures for use in the event of system failure;

i) the management of audit-trail and system log information (see 12.4);

j)  monitoring procedures.


Operating procedures and the documented procedures for system activities should be treated as formal documents and changes authorized by management. Where technically feasible, information systems should be managed consistently, using the same procedures, tools and utilities.

********************************************************************************

ISO/IEC 27002:2013(E)

2.1.1 形成文件的操作程序

控制

操作程序應記錄下來並提供給所有需要的使用者。


實施指導

應為與資訊相關的業務活動準備文件化的程序處理和通訊設施,例如電腦啟動和關閉程序、備份、設備維護、媒體處理、電腦室和郵件處理管理和安全。

操作規程應明確操作說明,包括:

a) 系統的安裝與配置;

b) 自動和手動處理和處理資訊;

c) 備份(見12.3);

d) 調度要求,包括與其他系統的相互依賴性、最早的作業開始時間和最晚的作業完成時間;

e) 處理作業執行期間可能出現的錯誤或其他異常情況的說明,包括系統實用程式使用的限制(請參閱 9.4.4);

f) 支援和升級聯繫,包括發生意外操作或技術困難時的外部支援聯繫;

g) 特殊輸出和媒體處理說明,例如特殊文具的使用或機密輸出的管理,包括安全處置失敗輸出的程序工作(見 8.3 和 11.2.7);

h) 系統故障時所使用的系統重新啟動與復原程序;

i) 稽核追蹤與系統日誌資訊的管理(見 12.4);

j) 監控程序。

系統活動的操作程序和文件化程序應被視為管理階層授權的正式文件和變更。在技​​術上可行的情況下,應使用相同的程序、工具和實用程式對資訊系統進行一致的管理。

********************************************************************************

ISO/IEC 27002:2013(E)


12.4.2 Protection of log information

Control

Logging facilities and log information should be protected against tampering and unauthorized access.


Implementation guidance

Controls should aim to protect against unauthorized changes to log information and operational problems with the logging facility including:

a) alterations to the message types that are recorded;

b) log files being edited or deleted;

c) storage capacity of the log file media being exceeded, resulting in either the failure to record events or over-writing of past recorded events.

Some audit logs may be required to be archived as part of the record retention policy or because of requirements to collect and retain evidence (see 16.1.7).


System logs often contain a large volume of information, much of which is extraneous to information security monitoring. To help identify significant events for information security monitoring purposes, the copying of appropriate message types automatically to a second log, or the use of suitable system utilities or audit tools to perform file interrogation and rationalization should be considered.

System logs need to be protected, because if the data can be modified or data in them deleted, their existence may create a false sense of security. Real-time copying of logs to a system outside the control of a system administrator or operator can be used to safeguard logs.

********************************************************************************

ISO/IEC 27002:2013(E)

12.4.2 日誌資訊保護

控制

應保護日誌記錄設施和日誌資訊免遭篡改和未經授權的存取。


實施指導

控制措施應旨在防止未經授權的日誌資訊變更和日誌記錄設施的操作問題,包括:

a) 更改記錄的訊息類型;

b) 編輯或刪除的日誌檔;

c) 超出日誌檔案媒體的儲存容量,導致無法記錄事件或覆蓋過去記錄的事件。

作為記錄保留政策的一部分或由於收集和保留證據的要求,某些審核日誌可能需要存檔(見 16.1.7)。


系統日誌通常包含大量資訊,其中許多資訊與資訊安全監控無關。為了幫助識別資訊安全監控目的的重要事件,應考慮將適當的訊息類型自動複製到第二個日誌,或使用適當的系統實用程式或審核工具來執行文件詢問和合理化。

系統日誌需要受到保護,因為如果資料可以被修改或其中的資料被刪除,它們的存在可能會產生錯誤的安全感。將日誌即時複製到系統管理員或操作員控制以外的系統可用於保護日誌。

********************************************************************************

(完)

[研究]NIST SP 800-53 Rev. 5 和 Rev. 5.1.1

[研究]NIST SP 800-53 Rev. 5 和 Rev. 5.1.1

2024-07-16

COMPUTER SECURITY RESOURCE CENTER - SP 800 所有文件列表
https://csrc.nist.gov/publications/sp800

SP 800-53 Rev.5   
Security and Privacy Controls for Information Systems and Organizations
資訊系統和組織的安全和隱私控制
Final    12/10/2020

********************************************************************************

NIST SP 800-53 Rev. 5
Security and Privacy Controls for Information Systems and Organizations
https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final

A list of all the changes 
https://csrc.nist.gov/files/pubs/sp/800/53/r5/upd1/final/docs/sp800-53r5-potential-updates.xlsx

********************************************************************************

Cybersecurity and Privacy Reference Tool CPRT
Security and Privacy Controls for Information Systems and Organizations, 5.1.1
November 7, 2023
https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_1_1/home

SP800.53.r5.1.1-FAQ.pdf
https://csrc.nist.gov/csrc/media/Projects/risk-management/documents/Additional%20Resources/SP800.53.r5.1.1-FAQ.pdf

********************************************************************************

(完)

2024年7月13日 星期六

[研究]WINWORD.EXE-應用程式錯設,應用程式無法正確啟動(0xC0000142)

[研究]WINWORD.EXE-應用程式錯設,應用程式無法正確啟動(0xc0000142)

2024-07-13


解決:

後來把 Windows Update 跑完,reboot 後正常。

(完)

2024年7月12日 星期五

[研究]圖形驗證(Captcha)、身分證、IP 算是 多因子驗證 MFA 的 因子嗎?

[研究]圖形驗證(Captcha)、身分證、IP  算是 多因子驗證 MFA 的 因子嗎?

2024-07-12、2024-07-18

多因子驗證/多因素驗證 (Multi-Factor Authentication, MFA)三種身分驗證類型

( Something you know, Something you have, Something you are )

( 所知之事、所有之物、所具之形)

( 所知因子、持有因子、生物因子)

至少包含2種。


註:雙因子驗證/雙因素驗證 (Two-Factor Authentication, TFA) 是剛好使用兩種因子。

********************************************************************************

NIST Special Publication 800-63-3 Digital Identity Guidelines

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-3.pdf

The classic paradigm for authentication systems identifies three factors as the cornerstones of authentication:

  • Something you know (e.g., a password).
  • Something you have (e.g., an ID badge or a cryptographic key).
  • Something you are (e.g., a fingerprint or other biometric data).

MFA refers to the use of more than one of the above factors. 

********************************************************************************

多重要素驗證的趨勢發展與分析 - 財團法人台灣網路資訊中心部落格 | TWNIC Blog

https://blog.twnic.tw/2022/12/20/25018/ 

目前主要的MFA身份驗證類型分別為:

  • 知識資訊(Something you know):例如使用者名稱、密碼
  • 持有資訊(Something you have):例如獨立的裝置、身分證、提款
  • 生物資訊(Something you are):例如臉部辨識、指紋辨識
  • 位置資訊(Somewhere you are):例如IP位址或地理資訊

MFA需要符合兩種以上「不同類型」的驗證方法,假設使用指紋辨識與臉部辨識登入,則因為皆屬於「生物資訊」而不符合MFA,最熟悉的方式莫過於在ATM提款時需要放入銀行卡片(Things you have)與輸入提款密碼(Things you know)。

********************************************************************************

圖形驗證(Captcha)  算是 多因素驗證(Multi-Factor Authentication, MFA) 的 所知資訊(Something you know)嗎 ?

ChatGPT

圖形驗證(Captcha)通常不被認為是多因素驗證(MFA)中的「Something you know」因素。這兩者在身份驗證安全性上有所不同:

  1. 圖形驗證(Captcha):這是一種用於區分人類和機器的技術,通常通過要求用戶識別圖片中的文字或圖形來進行驗證。Captcha確保正在進行操作的是真人而非自動化程式(如機器人)。
  2. 多因素驗證(MFA):MFA 是一種安全驗證方法,通常包括以下幾種因素之一或多種因素的結合:

    • Something you know(你所知道的):如密碼、PIN碼。
    • Something you have(你所擁有的):如智能卡、USB安全鍵、手機。
    • Something you are(你所是的):如生物特徵識別,例如指紋、視網膜掃描等。

Captcha主要是用來證明使用者是真人,並不涉及用戶特定的秘密信息或知識(something you know),因此它不屬於MFA中「Something you know」這個因素。

總結來說,Captcha和MFA都是用於增強身份驗證的安全性,但是它們解決的是不同的安全問題,並在驗證過程中使用不同類型的信息。

********************************************************************************

身分證號碼  算是 多因素驗證(Multi-Factor Authentication, MFA) 的 所知資訊(Something you know)嗎 ?

ChatGPT

身分證號碼通常被視為多因素驗證(MFA)中的「Something you know」因素的一部分,但這要視具體情況而定。

在某些情況下,身分證號碼確實可以被視為「Something you know」,因為它是一種具有唯一性和私密性的個人識別信息,只有合法的使用者才應該知道自己的身分證號碼。在這種情況下,當用戶輸入正確的身分證號碼時,可以作為驗證其身份的一部分。

然而,需要注意的是,單獨的身分證號碼可能不足以提供足夠的安全性,因此通常會將其與其他因素結合,例如密碼、PIN碼、生物特徵等,來實現更強大的多因素驗證(MFA)機制。

總結來說,身分證號碼可以被視為MFA中「Something you know」的一部分,但在實際應用中,建議與其他驗證因素結合,以提升安全性。

********************************************************************************

身分證號碼  算是 多因素驗證(Multi-Factor Authentication, MFA) 的 Something you have(你所擁有的)嗎 ?

ChatGPT

身分證號碼通常不算是多因素驗證(MFA)中的「Something you have」(你所擁有的)因素。

「Something you have」通常指的是具體的物理或虛擬物件,例如:

  • 智能卡
  • USB安全鍵
  • 手機或其他設備
  • 硬件驗證器(如硬體令牌)

這些物件是實體存在的,並且在驗證過程中可以被用戶控制和擁有。身分證號碼雖然是一種識別信息,但它本身不是用戶擁有或控制的具體物件,因此不符合「Something you have」這一因素的定義。

身分證號碼更適合作為「Something you know」(你所知道的)的一部分,因為它是用戶所知道的私密信息之一。

********************************************************************************

多重要素驗證 - 維基百科,自由的百科全書

https://zh.wikipedia.org/zh-tw/%E5%A4%9A%E9%87%8D%E8%A6%81%E7%B4%A0%E9%A9%97%E8%AD%89

  • 知識要素:例如使用者名稱及密碼
  • 持有的物件:例如獨立的裝置、安全權杖、身分證、提款卡等等
  • 原生要素:生物特徵:例如臉部辨識、指紋辨識、語音辨識

********************************************************************************

身分證卡片  算是 多因素驗證(Multi-Factor Authentication, MFA) 的 Something you have(你所擁有的)嗎 ?

ChatGPT

身分證卡片通常可以被視為多因素驗證(MFA)中的「Something you have」(你所擁有的)因素。

多因素驗證(MFA)通常涉及以下幾種因素之一或多個因素的組合來確認使用者身份:

  • Something you know(你所知道的):例如密碼、PIN碼、安全問題的答案等。
  • Something you have(你所擁有的):例如智能卡、USB安全鍵、手機或身分證卡片等。
  • Something you are(你所是的):例如生物特徵識別,如指紋、視網膜掃描等。

身分證卡片作為一種具體的物理證件,可以被用戶擁有和控制,並且通常是由官方機構發放,具有一定的唯一性和可信度。因此,當身分證卡片用於身份驗證時,它可以被歸類為MFA中的「Something you have」因素。

總結來說,身分證卡片作為一種實體物件,通常能夠有效增強身份驗證的安全性,因此在MFA策略中常常被使用。

********************************************************************************

有讀卡機可以讀取身分證卡片中的身分證號碼嗎 ?

ChatGPT

是的,有讀卡機可以讀取台灣的身分證卡片中的身分證號碼。這些讀卡機可以透過內建的軟體來讀取內含的資訊,包括身分證號碼、姓名、生日等個人資料。通常使用這些讀卡機需要搭配特定的應用軟體,並且用戶可能需要授權才能讀取和使用這些資料。

如果你有任何特定的需求或問題,歡迎告訴我,我可以幫助你找到更多相關資訊。

********************************************************************************

自然人憑證讀卡機可以讀取台灣身分證卡片中的身分證號碼嗎 ?

ChatGPT

自然人憑證讀卡機主要設計用來讀取自然人憑證,這是一種含有數位憑證的智慧卡。台灣的身分證卡片(新版的 IC 身分證)也使用類似的智慧卡技術,但自然人憑證讀卡機能否讀取台灣身分證卡片中的身分證號碼,取決於讀卡機的軟體是否支援此功能。

大多數自然人憑證讀卡機硬體上應該是可以讀取身分證卡片的,但是你可能需要相應的軟體來解碼並提取身分證中的資料。一般來說,專門設計的 IC 身分證讀卡機和配套軟體會更適合這個用途。

簡而言之,自然人憑證讀卡機理論上可以讀取台灣身分證卡片中的身分證號碼,但需要確保你有相應的軟體支援和授權。

********************************************************************************

手機號碼驗證碼

登入時,輸入帳號密碼後,系統根據帳號密碼從資料庫找出該使用者手機號碼,寄出一個驗證碼到該手機號碼,於網頁上請使用者輸入驗證通過後才能登入成功,此手機號碼驗證碼算是MFA的 Something you have(你所擁有的) 嗎 ? Something you know(你所知道的)嗎 ? 不算 ?

ChatGPT

手機號碼驗證碼屬於多因素驗證(MFA)中的 "Something you have"(你所擁有的)。以下是詳細的解釋:

  • Something you know(你所知道的):這類包括密碼、PIN 碼等,是使用者頭腦中記住的信息。
  • Something you have(你所擁有的):這類包括實體令牌、智慧卡、手機等設備。手機驗證碼屬於這一類,因為它需要你擁有並能接收短信的手機。
  • Something you are(你所代表的):這類包括生物特徵識別,如指紋、面部識別、虹膜掃描等。

因此,當系統發送驗證碼到手機號碼並要求輸入該驗證碼時,這個驗證碼代表了 "Something you have"。

********************************************************************************

Email驗證碼

登入時,輸入帳號密碼後,系統根據帳號、密碼從資料庫找出該使用者Email,寄出一個驗證碼到該Email,於網頁上請使用者輸入驗證通過後才能登入成功,此Email中的驗證碼算是MFA的 Something you have(你所擁有的) 嗎 ? Something you know(你所知道的)嗎 ? 不算 ?

ChatGPT

當系統發送驗證碼到電子郵件並要求輸入該驗證碼時,這個驗證碼的類別有點複雜。根據多因素驗證(MFA)的分類:

  • Something you know(你所知道的):這類包括密碼、PIN 碼等,是使用者頭腦中記住的信息。
  • Something you have(你所擁有的):這類包括實體令牌、智慧卡、手機等設備。某些情況下,訪問電子郵件帳戶也可以被視為 "Something you have"。
  • Something you are(你所代表的):這類包括生物特徵識別,如指紋、面部識別、虹膜掃描等。

在這種情況下,電子郵件驗證碼既不完全屬於 "Something you know"(你所知道的),也不完全屬於 "Something you have"(你所擁有的)。它更傾向於 "Something you have" 的概念,因為它涉及訪問一個特定的電子郵件帳戶,就像訪問手機接收短信一樣。然而,這種分類在某些情況下可能會有所爭議,因為電子郵件本身是通過知道密碼來訪問的。

總結來說,電子郵件驗證碼更接近於 "Something you have"。

********************************************************************************

系統的來源 IP 限制

系統的來源 IP 限制,算是多因素驗證(MFA)的一種因子嗎? Something you have(你所擁有的) 嗎 ? Something you know(你所知道的)嗎 ? 不算 ?

ChatGPT

系統的來源 IP 限制通常不被視為多因素驗證(MFA)的一種因子。以下是原因:

  • Something you know(你所知道的):IP 限制是基於系統設置,用戶不需要特別知道或記住任何額外信息,因此不符合這個分類。
  • Something you have(你所擁有的):這通常指實體設備、智慧卡、手機等,用戶必須擁有或可以控制這些因子。

IP 限制屬於一種訪問控制的技術,而非用戶身份驗證的因子。它通常用於增加安全性,限制從特定位置或網路訪問資源的範圍,但並不涉及用戶個人身份的驗證。

********************************************************************************

OTP(一次性密碼,One Time Password)設備,算是 MFA 因子?哪一種?

ChatGPT

OTP(一次性密碼,One Time Password)設備確實是多因素驗證(MFA)的一種因子。它屬於以下類別:

Something you have(你所擁有的):OTP 設備是一個實體設備(如硬體令牌或手機上的 OTP 應用程式),使用者必須擁有這個設備來生成或接收一次性密碼。

總結來說,OTP 設備是多因素驗證中的 "Something you have(你所擁有的)" 因子。

********************************************************************************

如果根據使用者登入 AD 網域,由 DHCP 配給非固定 IP,算 MFA 的因子?哪一種?

如果根據 帳號 配給 固定 IP,算 MFA 的因子?哪一種?

如果根據 網路卡 MAC Address 配給 固定 IP,算 MFA 的因子?哪一種? 

ChatGPT

關於 IP 和 MAC 地址在多因素驗證(MFA)中的角色,可以進一步分析如下:

  • 根據使用者登入 AD 網域,由 DHCP 配給非固定 IP:這並不算是多因素驗證的一部分。DHCP 配給非固定 IP 是一種網絡管理技術,並不涉及用戶身份驗證。
  • 根據帳號配給固定 IP:這種方法也不算是 MFA 的一個因子。配給固定 IP 是基於帳號的網絡配置方式,並不是一種用戶身份驗證因子。
  • 根據網絡卡 MAC 地址配給固定 IP:這種方法可以被視為一種設備識別技術,但也不算作 MFA 的一個因子。雖然 MAC 地址可以唯一標識一個設備,但它不是傳統意義上的用戶驗證因子。

總結來說,這些方法主要是網絡管理和訪問控制技術,這些技術主要是用於增加安全性和控制訪問,而不是用戶身份驗證的一部分。

********************************************************************************

(完)

[研究]PotPlayer 播放影片有聲音,但畫面全黑

[研究]PotPlayer 播放影片有聲音,但畫面全黑

2024-07-12

Windows Media Player 和 KMPlayer 播放影片正常,PotPlayer 播放影片有聲音,但畫面全黑;把 PotPlayer 移除,重新安裝,無用;「滑鼠右鍵/偏好設定(F5)/初始化」,也無用;如何解 ?

ChatGPT

PotPlayer 播放影片時有聲音但畫面全黑的問題,可能與視頻設置、編解碼器或顯示驅動有關。這裡有一些步驟可以幫助解決這個問題:

1.檢查視頻渲染器設置:

  • 打開 PotPlayer。
  • 右鍵點擊播放器界面,選擇「選項」(Preferences)。
  • 在「視頻」(Video)選項下,找到「視頻渲染器」(Video Renderer)。
  • 嘗試更改視頻渲染器,例如從「內部DX9渲染器」(Internal DX9 Renderer)更改為「EVR」(Enhanced Video Renderer)或「Madshi視頻渲染器」(Madshi Video Renderer)等。

2.更新編解碼器:

  • 有時候,編解碼器可能出現問題,嘗試更新編解碼器。
  • 在 PotPlayer 的「選項」(Preferences)中,找到「編解碼器/過濾器」(Codec/Filter)。
  • 選擇「視頻解碼器」(Video Decoder),確認所有解碼器已更新到最新版本,或者嘗試更改使用內建解碼器或外部解碼器。

3.更新顯示驅動程式:

  • 有時候,顯示驅動程式的問題可能會影響視頻播放。
  • 前往你的顯示卡製造商的網站(如 NVIDIA、AMD、Intel)下載並安裝最新的顯示驅動程式。

4.檢查 DirectX:

  • 確保你的系統已安裝最新版本的 DirectX。
  • 你可以從微軟的官網下載並安裝最新版本的 DirectX。

5.重置 PotPlayer 設置:

  • 如果以上方法無效,嘗試重置 PotPlayer 的所有設置。
  • 打開 PotPlayer,右鍵點擊播放器界面,選擇「選項」(Preferences)。
  • 在左側選單中找到「重置」(Reset),點擊並確認重置所有設置。

6.檢查視頻文件:

  • 嘗試播放不同的視頻文件,以確定問題是否與特定文件有關。如果其他文件可以正常播放,則可能是特定文件的問題。

如果以上步驟仍無法解決問題,可以考慮使用其他視頻播放器,如 VLC Media Player,或者在 PotPlayer 的論壇和社群尋求幫助。

**********

最後選【EVR (Vista/.Net3)】解決;選第2個【視訊渲染器】也成功。

(完)

2024年7月5日 星期五

[研究]SQL Server 2019 的 磁碟區陰影複製服務 (VSS, Volume Shadow Copy Service) 啟用、停用 各有甚麼優點?缺點?

[研究]SQL Server 2019 的 磁碟區陰影複製服務 (VSS, Volume Shadow Copy Service) 啟用、停用 各有甚麼優點?缺點?

2024-07-05

SQL Server 2019 的 磁碟區陰影複製服務 (VSS, Volume Shadow Copy Service) 啟用、停用 各有甚麼優點?缺點?

ChatGPT

啟用和停用 SQL Server 2019 的磁碟區陰影複製服務 (VSS, Volume Shadow Copy Service) 各有其優點和缺點。以下是一些主要的考量點:

啟用 VSS

優點

  1. 一致性備份:(1)VSS 可以創建一致性快照,確保資料在備份過程中不會受到損害。(2)可以進行在線備份,不需要停止 SQL Server 服務。
  2. 減少停機時間:使用 VSS,可以在不中斷服務的情況下進行備份,對於需要高可用性和低停機時間的系統尤為重要。
  3. 備份速度快:快照通常比傳統備份更快,因為它只需要複製變更的區塊,而不是整個數據庫。
  4. 輕鬆恢復:快照使得恢復數據更加方便和快速,尤其是在處理大數據庫的情況下。

缺點

  1. 性能影響:雖然 VSS 快照是在線進行的,但仍然會對系統性能產生一些影響,特別是在快照創建的過程中。
  2. 磁碟空間:快照需要額外的磁碟空間來存儲變更的數據塊,這可能會增加存儲成本。
  3. 複雜性:配置和管理 VSS 可能比傳統備份方式更加複雜,需要額外的知識和技能。


停用 VSS

優點

  1. 簡化管理:傳統備份方式相對較簡單,易於管理和配置。
  2. 性能穩定:傳統備份通常在非高峰期執行,不會對系統性能造成顯著影響。
  3. 節省磁碟空間:不需要為快照保留額外的磁碟空間,可能會節省存儲成本。

缺點

  1. 停機時間:傳統備份可能需要停止 SQL Server 服務,特別是在進行全量備份時。
  2. 備份速度慢:傳統備份通常比快照慢,特別是在處理大數據庫時。
  3. 恢復時間長:傳統備份的恢復過程通常比快照恢復慢,這在需要快速恢復的情況下可能會成為瓶頸。

綜合考量,是否啟用 VSS 應根據具體的業務需求和系統環境來決定。如果系統需要高可用性和快速恢復,並且有足夠的磁碟空間,那麼啟用 VSS 可能是一個更好的選擇。而如果系統更看重穩定性和簡單性,停用 VSS 並使用傳統備份方式可能更為合適。

**********

請問下面這個缺點的資料來源網址 ?

"傳統備份可能需要停止 SQL Server 服務,特別是在進行全量備份時。"

ChatGPT

傳統備份通常不需要停止 SQL Server 服務,即使是全量備份。在現代的 SQL Server 環境中,傳統的全量備份和差異備份都是在線進行的,不會中斷服務。我的錯誤陳述可能引起了誤解,並且缺乏實際資料來源的支持。

SQL Server 支援在線備份,即使在全量備份的情況下,系統仍然可以繼續運行並處理查詢。這是現代數據庫管理系統的一個重要特性,確保了高可用性和最小的停機時間。

再次抱歉之前的錯誤陳述,感謝你的指正。

********************************************************************************

2024-08-28 補

發現 Windows Update 當月如果包含 SQL Server Update,

Windows「服務」中的「SQL Server VSS Writer」會再次被設定為「執行中」「自動」。

Imperva DAM 會再次不定時出現 HIPAA - Attempt to backup database 通知信。(就算該時間點不是你在 SQL Server Management Studio (SSMS) 中「管理」「維護計畫」設定的自動備份時間點 )

********************************************************************************

請問 SQL Server 的 VSS 何時 ? 或何種狀況 ? 會自動執行 

ChatGPT 說:

SQL Server 不會自行觸發 VSS(Volume Shadow Copy Service)快照。VSS 快照的執行通常是由外部備份軟件或系統管理員設定的腳本來觸發,並非由 SQL Server 自行控制或啟動。

不過,在以下情況下,SQL Server 的資料庫可能會在 VSS 快照過程中被自動納入:

  1. 使用 VSS 驅動的備份軟件:當您使用支持 VSS 的備份軟件(如 Windows Server Backup、System Center Data Protection Manager、或第三方工具)來備份整個系統或特定卷,該軟件可能會調用 VSS 來生成 SQL Server 資料庫的快照。在這種情況下,SQL Server 會自動與 VSS 協調,確保在快照期間資料的一致性。
  2. 系統還原點:在 Windows 系統中,如果啟用了系統還原功能,系統可能會自動在某些事件(如安裝軟件、Windows Update)發生前創建還原點。此過程也會使用 VSS 技術,並可能包含正在運行的 SQL Server 資料庫。
  3. 第三方自動化腳本:有時候,系統管理員可能會設計自動化腳本,定期調用 VSS 來創建 SQL Server 資料庫的快照,這樣的腳本可以配置成根據特定的時間表運行。

自動執行的條件

  1. 外部驅動:如前述,VSS 的自動執行通常由外部備份工具或操作系統進行管理,而非由 SQL Server 自行管理。
  2. 與操作系統的整合:當備份操作涉及到使用 VSS,SQL Server 通常會與操作系統協調,這樣當操作系統要求時,SQL Server 會暫停寫入操作,並確保數據一致性。

簡而言之,SQL Server 本身不會自動執行 VSS,但在涉及系統備份、還原點創建、或使用第三方工具的過程中,SQL Server 資料庫可能會被自動包括在 VSS 快照中。

********************************************************************************

請問 Windows Server 何種狀況  會自動觸發 SQL Server 的 VSS 執行 ?

ChatGPT 說:

在 Windows Server 中,自動觸發 SQL Server 的 VSS(Volume Shadow Copy Service)通常發生在以下情況:

1. 系統還原點(System Restore Points)

當 Windows Server 執行系統更新、安裝新的軟體或驅動程式時,系統可能會自動創建還原點。這個過程會使用 VSS 技術來生成快照,以便將系統還原到之前的狀態。如果 SQL Server 資料庫托管在被創建快照的磁碟區上,它們將被包括在 VSS 快照中。

2. 系統備份

當 Windows Server 使用內建的備份工具(如 Windows Server Backup)執行全系統或特定磁碟區的備份時,VSS 將自動啟動以創建快照。在備份過程中,如果該磁碟區包含 SQL Server 的資料庫,這些資料庫將自動被納入快照中。

3. 第三方備份軟件

許多第三方備份工具(如 Symantec Backup Exec、Veeam Backup & Replication、System Center Data Protection Manager 等)在執行系統或應用程序備份時會自動觸發 VSS。這些工具通常會使用 VSS 來確保資料庫的一致性。在這種情況下,SQL Server 的 VSS 會被自動觸發來生成一致性快照。

4. 定期排程的系統快照

如果 Windows Server 配置了定期的快照策略,例如定期創建卷影複製(Shadow Copies)來保護文件系統中的數據,這些快照將使用 VSS。如果 SQL Server 的資料庫位於受保護的磁碟區上,這些資料庫將在快照中被保護。

5. 安裝或卸載應用程序

在安裝或卸載某些需要保證系統穩定性和一致性的應用程序時,Windows 可能會自動創建一個還原點。這個過程同樣會觸發 VSS 來創建包含 SQL Server 資料庫的快照。

自動觸發的關鍵點:

VSS 是由操作系統或備份工具調用:當這些工具需要保護包含 SQL Server 資料庫的磁碟區時,VSS 會被自動調用。

資料庫的一致性:當 VSS 被觸發時,SQL Server 會與 VSS 協同工作,以確保在創建快照期間資料庫處於一致的狀態。

如果您正在管理 SQL Server 並需要控制何時創建 VSS 快照,最好配置適當的備份策略或使用專門的備份工具來控制這一過程。

********************************************************************************

(完)

[研究]Imperva DAM 一堆 SQL Server 資料庫備份警訊通知信原因

[研究]Imperva DAM 一堆 SQL Server 資料庫備份警訊通知信原因 

2024-07-05

(下圖) SQL Server 2019 的 SSMS (SQL Server Management Studio) 明明設定一天備份一次,不定時收到通知 Email,明明沒備份 master,但通知信有一封是 master 備份


(下圖)
把 Windows 服務中的 "SQL Server VSS Writer" 改成 "手動",並停用它


磁碟區陰影複製服務 (VSS)
Volume Shadow Copy Service (VSS) 




[研究]SQL Server 2019 的 磁碟區陰影複製服務 (VSS, Volume Shadow Copy Service) 啟用、停用 各有甚麼優點?缺點?

(完)

相關

SQL Server 備份應用程式 - 磁碟區陰影複製服務 (VSS) 和 SQL 寫入器
https://learn.microsoft.com/zh-tw/sql/relational-databases/backup-restore/sql-server-vss-writer-backup-guide?view=sql-server-ver16
SQL Server Backup Applications - Volume Shadow Copy Service (VSS) and SQL Writer
https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/sql-server-vss-writer-backup-guide?view=sql-server-ver16

SQL Writer service
https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/sql-writer-service?view=sql-server-ver16
SQL 寫入器服務
https://learn.microsoft.com/zh-tw/sql/database-engine/configure-windows/sql-writer-service?view=sql-server-ver16

SQL Server VSS Writer 記錄

https://learn.microsoft.com/zh-tw/sql/relational-databases/backup-restore/sql-server-vss-writer-logging?view=sql-server-ver16