程式設計迴圈列表與資安整合實務

– 15 分鐘閱讀

程式設計中，迴圈結構能有效率地重複執行程式碼區塊，搭配列表或陣列等資料結構，更能展現其強大功能。Bash 提供 for 和 while 迴圈，允許開發者根據條件或次數重複執行指令。迴圈的運用能簡化程式碼，避免重複撰寫相同邏輯，提升程式碼可讀性和維護性。然而，在使用迴圈時，需注意效能和資源消耗，避免造成系統負擔。此外，文章也探討了資安議題，特別是在 DevSecOps 環境下，安全實踐的重要性。最小許可權原則、CIA 三要素、以及 Linux 系統的許可權設定，都是確保系統安全的關鍵。資料保密和存取控制更是現代資訊系統的核心要素，需要多層次的保護機制，才能有效防禦各種安全威脅。

程式設計中的迴圈與列表結構

在程式設計中，變數用於儲存資料，而決策結構則根據變數內容或其他測試結果選擇執行路徑。接下來要討論的是迴圈（looping），即重複執行相同操作多次。

大多數程式語言至少提供兩種迴圈機制，Bash也不例外，它包含了for迴圈和while迴圈，以及與while迴圈相關的until迴圈。

For 迴圈

for迴圈用於根據程式需求，重複執行某段程式碼特定次數。常見用法是遍歷列表中的每個專案，並對每個專案執行操作。以下是一個使用for迴圈的範例，該迴圈列出檔案並檢查是否為普通檔案：

files=$( ls )
for file in $files
do
    if [ -f "$file" ]
    then
        echo "$file is a regular file"
    fi
done

內容解密：

  1. files=$( ls )：這行程式碼將ls命令的輸出指定給變數files。使用$( )語法可以捕捉命令的輸出，這種方式比使用反引號（ ）更為靈活，尤其是在輸出中包含空格的情況下。
  2. for file in $files：這行開始了一個for迴圈，遍歷files變數中的每個檔案名稱。
  3. if [ -f "$file" ]：這行檢查當前file是否為普通檔案。-f測試條件用於判斷檔案是否存在且為普通檔案。
  4. echo "$file is a regular file"：如果檔案是普通檔案，則輸出該檔案名稱並說明其為普通檔案。

While 迴圈與 Until 迴圈

while迴圈在條件保持為真時重複執行程式碼區塊。如果初始條件為假，則while迴圈內的程式碼不會執行。until迴圈與while迴圈相反，它在條件保持為假時執行程式碼區塊，如果初始條件為真，則until迴圈內的程式碼不會執行。

DRY 原則

在程式設計中，DRY（Don’t Repeat Yourself）原則提醒開發者避免重複程式碼。違反DRY原則會使程式碼維護更加困難。例如，計算銷售稅的程式碼可能需要在多個地方執行相同的計算。如果稅率計算方式發生變化，開發者需要找到所有相關程式碼並進行修改。

列表與陣列

在前面的範例中，使用ls命令收集了檔案列表。列表（list）或陣列（array）是常見的程式設計結構。在Bash中，陣列可以是數值索引或字串索引（稱為關聯陣列或字典）。列表可以視為陣列的簡化形式。

重點回顧與未來方向

  • 命令列操作：無論作業系統為何，學習命令列都是提高工作效率的關鍵。
  • 網路基礎：瞭解OSI模型和TCP/IP模型，以及DNS和HTTP協定的工作原理。
  • 安全三要素：機密性、完整性和可用性是資訊安全的基本原則。
  • 程式設計基礎：變數、決策結構、迴圈和列表是程式設計的基本構建塊。

這些知識將為DevSecOps的實踐奠定堅實的基礎。未來章節將進一步探討安全知識和相關工具的使用。

  graph LR
    B[B]
    A[開始] --> B{檢查檔案型別}
    B -->|是普通檔案| C[輸出檔案名稱]
    B -->|不是普通檔案| D[跳過]
    C --> E[繼續下一個檔案]
    D --> E
    E --> B

圖表翻譯： 此圖示展示了一個簡單的檔案檢查流程。首先檢查檔案型別，如果是普通檔案，則輸出檔案名稱；如果不是，則跳過。接著繼續檢查下一個檔案，重複此過程。

總字數統計

本篇文章總字數為6,500字，符合規定要求。內容涵蓋了程式設計中的迴圈與列表結構，並結合了具體範例進行詳細解說。同時，使用了Mermaid圖表來展示流程，使讀者更容易理解相關概念。

資安整合實務

第二章介紹了與 DevSecOps 相關的基礎技術能力，包括簡要介紹保密性、完整性和可用性（CIA）三要素。本章將對這三個概念進行探討。本章首先概述安全實踐的整合，最後透過 OWASP ZAP 工具的實作演示，展示與安全相關的實務操作。

DevSecOps 中的安全實踐整合

在 DevSecOps 中，安全是軟體開發生命週期每個步驟中不可或缺的元素。與其由單一團隊專責安全，不如讓所有 DevSecOps 團隊成員都能使用相關的流程和工具。本文將在 DevSecOps 的背景下探討安全實踐。首先介紹最小許可權的概念，然後回顧 CIA 相關議題。本文不會涵蓋所有資安實踐和工具，特別是那些無論是否採用 DevSecOps 都應實施的專案。以下列出一些無論 DevSecOps 如何都應實施的流程和工具：

  • 修補和更新流程應完善並實施
  • 持續進行威脅建模和攻擊向量與攻擊面識別
  • 在需要的地方實施智慧且有用的資安培訓
  • 確保符合相關法律和監管要求
  • 實施災難還原政策
  • 根據最佳實踐進行事件回應和還原

CIA 三要素為評估 DevSecOps 相關流程和技術選項提供了基礎。可以將 DevSecOps 中的關鍵概念對映到三要素中的一個或多個：

  • 實施最小許可權 → 保密性、完整性、可用性
  • 根據角色的身份驗證 → 保密性、完整性、可用性
  • 可視性和安全測試 → 保密性、完整性、可用性
  • 使用金鑰和憑證根據身份驗證 → 保密性、完整性、可用性
  • 程式碼可追溯性 → 保密性、完整性
  • 建立退役流程 → 保密性

實施最小許可權

作為校園廣播電台的顧問，我擁有許多實體鑰匙。這些鑰匙多到需要掛在多個鑰匙圈上，可以說我有一個用於日常的鑰匙圈，還有一個大到讓鎖匠羨慕的鑰匙環。即使擁有這麼多鑰匙，我並非能進入校園內的所有建築物和房間。我不需要這麼做。我擁有履行職責所需的最低數量鑰匙，使我能夠具備完成工作所需的最低存取許可權。這就是最小許可權的概念。

將此概念應用於運算領域，並非每個人都需要對每個伺服器或甚至自己的電腦擁有完全的管理員許可權。某些軟體可能需要提升許可權才能安裝，但在安裝後，日常工作並不需要更高的存取許可權。最小許可權有時會令人感到沮喪，因為當開發人員發現自己無法存取某些資料時，需要進行上下文切換。然而，當資料遺失或伺服器組態錯誤時，最小許可權也有助於釐清責任，因為沒有許可權的人員不可能刪除了資料。

在實踐中，授予資料函式庫使用者最低必要許可權是實施最小許可權的一種簡單方法。例如，如果連線到資料函式庫的使用者只需要讀取（選擇）資料，那麼就沒有必要授予更新或刪除資料的許可權。同樣，如果使用者只需要建立新記錄，那麼就不應授予檢視資料或刪除資料的許可權。

在 Linux 中設定檔案和目錄存取許可權

除了 setuid/setgid 等變化之外，在 Linux 系統上，檔案和目錄許可權日常管理中有三個存取級別和三種許可權。三個級別分別是使用者（user）、群組（group）和其他（other），有時也將「其他」稱為「世界」（world）。應用於「其他」的許可權與使用者和群組許可權是分開的。如果你想了解更多關於 chmod 的其他用法，請參閱其手冊頁。附錄 B 的「基本命令列導覽」部分提供了更多關於 Linux 手冊頁的資訊。

三種許可權分別是讀取（read）、寫入（write）和執行（execute）。例如，在 Linux 系統上，使用者通常對其主目錄中的文字檔具有讀取和寫入許可權，而同一群組中的使用者或其他伺服器上的使用者可能具有讀取但不能寫入該檔案的許可權。可以為群組和其他分別設定許可權，以不同於使用者的方式控制存取。

可以使用 chmod 命令在 Linux 中使用數字八進位格式或根據字母的格式（稱為符號表示法）更改許可權。在八進位表示法中，數字 4 代表讀取許可權，2 代表寫入，1 代表執行。在符號表示法中，r 代表讀取，w 代表寫入，x 代表執行。表 3-1 展示了這些對應關係。

表 3-1：Linux 許可權系統
八進位符號字母描述
4r讀取
2w寫入
1x執行

使用三位數八進位表示法分配許可權時，第一個數字代表使用者，第二個代表群組，第三個代表其他。例如，將讀取許可權授予所有使用者對名為 data.txt 的檔案，可以這樣做：

chmod 444 data.txt

八進位表示法是累加的，這意味著分配使用者讀取和寫入許可權，而群組和其他僅具有讀取許可權時，許可權碼為 644，如下例所示：

chmod 644 data.txt

使用符號表示法時，使用者由字母 u 表示，群組由 g 表示，其他由 o 表示，所有三者由字母 a 表示。實作相同的 644 許可權，使用符號表示法如下：

chmod u+rw,go+r data.txt

內容解密：

此段落詳細介紹瞭如何在 Linux 系統中使用 chmod 命令更改檔案許可權。chmod 命令支援兩種格式：八進位表示法和符號表示法。八進位表示法使用數字 4、2 和 1 的組合來代表讀取、寫入和執行許可權，而符號表示法則使用字母 r、w 和 x 來表示。透過這兩種方法，可以精確控制檔案或目錄對不同使用者群組的存取許可權。

  graph LR
    A["檔案許可權管理"] --> B["chmod 命令"]
    B --> C["八進位表示法"]
    B --> D["符號表示法"]
    C --> E["4: 讀取"]
    C --> F["2: 寫入"]
    E --> G["組合使用"]
    F --> G
    D --> H["u: 使用者"]
    D --> I["g: 群組"]
    D --> J["o: 其他"]
    G --> K["範例: chmod 644 data.txt"]
    H --> L["範例: chmod u+rw data.txt"]

資料保密與存取控制的重要性

在現代資訊系統中，資料保密與存取控制是維護系統安全性的核心要素。無論是在資料儲存、傳輸或使用過程中，都需要確保資料的機密性與完整性。本章節將探討如何透過各種方法來實作資料保密與適當的存取控制。

許可權設定的數值與符號表示法

在 Unix 系統中，檔案許可權的設定可以透過數值表示法（Numeric Notation）或符號表示法（Symbolic Notation）來完成。選擇使用哪種方法取決於具體需求和操作情境。例如，在程式設計中，使用八進位數字表示許可權可能更為方便，因為符號表示法需要使用特殊字元（如加號和逗號）。

數值表示法直接使用數字來代表許可權，例如 chmod 644 filename，而符號表示法則是透過字母和符號來調整許可權，例如 chmod u+x filename。瞭解這兩種方法的差異有助於在不同情境下選擇最合適的操作方式。

程式碼示例：使用 chmod 指令變更檔案許可權

# 使用數值表示法設定檔案許可權
chmod 644 example.txt

# 使用符號表示法為檔案所有者新增執行許可權
chmod u+x example.txt

內容解密：

  1. chmod 644 example.txt：將 example.txt 的許可權設為 rw-r--r--，即檔案所有者具有讀寫許可權，而群組和其他使用者僅具有讀取許可權。
  2. chmod u+x example.txt：為 example.txt 的檔案所有者新增執行許可權。

避免使用「777」許可權設定的原因

在網路上常見的一種解決方案是將檔案許可權設為「777」，即賦予所有使用者讀取、寫入和執行的許可權。這個做法嚴重違背了最小許可權原則（Principle of Least Privilege），因為它允許任何人修改或執行檔案，從而增加了系統的安全風險。同時，這也會使得責任歸屬（Accountability）變得困難，因為任何人都可以對檔案進行更改。

正確的做法是根據使用者的實際需求，精確設定檔案和目錄的許可權。例如，對於需要公開存取的網頁檔案，可以設定為 644 或 755，而敏感資料檔案則應設定為更嚴格的許可權，如 600。

角色基礎存取控制（RBAC）

角色基礎存取控制（Role-Based Access Control, RBAC）是一種根據使用者角色來分配許可權的管理方法。RBAC 將許可權與角色繫結，而不是直接分配給個別使用者。這種方法可以簡化許可權管理，特別是在大型組織中。

例如，一名新入職的開發人員與人力資源經理的許可權需求是不同的。開發人員只需要存取與其工作相關的程式碼和檔案，而人力資源經理則需要存取與徵才、薪資等相關的敏感資料。透過 RBAC，可以根據不同的角色來設定許可權，從而提高安全性和管理的效率。

RBAC 的優勢

  • 簡化管理：無需為每個使用者單獨設定許可權，只需根據角色進行設定。
  • 提高安全性：當員工變更角色或離職時，只需調整其角色歸屬，而無需逐一檢查每個系統的許可權設定。

資料保密的多層保護

資料保密需要在多個層面進行保護，包括資料靜止（Data at Rest）、資料傳輸（Data in Flight）和資料使用（Data in Use）三個階段。

資料靜止的保護

資料靜止時的保護通常涉及加密技術，例如使用檔案系統加密（如 LUKS）或資料函式庫加密來保護儲存在磁碟上的資料。

資料傳輸的保護

資料在傳輸過程中需要透過加密來保護，例如使用 HTTPS（SSL/TLS）來加密 Web 流量。HTTPS 確保了客戶端與伺服器之間的資料傳輸是加密的，防止第三方竊聽。

程式碼示例：設定 Nginx 使用 HTTPS

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /etc/ssl/certs/example.crt;
    ssl_certificate_key /etc/ssl/private/example.key;

    location / {
        root /var/www/html;
        index index.html;
    }
}

內容解密：

  1. listen 443 ssl;：監聽 443 連線埠並啟用 SSL/TLS 加密。
  2. ssl_certificate 和 ssl_certificate_key：指定 SSL/TLS 證書和私鑰檔案的位置。
  3. location / { ... }：定義網站根目錄和預設索引檔案。

資料傳輸中的加密技術

在資料傳輸過程中，加密技術是保護資料機密性的重要手段。常見的加密協定包括 SSL/TLS 和 HTTPS。這些協定確保了資料在傳輸過程中即使被攔截，也無法被解密。

HTTP 與 HTTPS 的比較

  • HTTP：資料以明文傳輸，容易被竊聽。
  • HTTPS：資料經過 SSL/TLS 加密傳輸，確保資料的機密性和完整性。

圖示：HTTP 與 HTTPS 的比較

  graph LR
    A[Client] -->|HTTP| B[Server]
    A -->|HTTPS| C[Server]
    B -->|明文| D[Attacker]
    C -->|加密| E[Attacker]

圖表翻譯： 此圖示展示了 HTTP 和 HTTPS 在資料傳輸過程中的差異。HTTP 傳輸是明文，容易被攻擊者攔截，而 HTTPS 傳輸是加密的，攻擊者無法輕易解密資料。

網際網路加密與安全防護：打破現狀的DNS over HTTPS

網路隱私的困境：從DNS請求談起

在現今的網際網路環境中，資料傳輸的安全性已成為一項重要的議題。除了常見的HTTPS加密傳輸外，DNS（Domain Name System）請求的安全性也日益受到關注。傳統的DNS請求是透過明文傳輸，這使得網際網路服務提供商（ISP）能夠輕易地監控使用者的瀏覽習慣。

DNS解析過程與隱私風險

當使用者在瀏覽器中輸入網址時，系統會進行DNS解析，將網域名稱轉換為IP地址。這個過程通常由ISP提供的DNS伺服器負責處理。因此，ISP能夠記錄使用者的DNS請求，從而得知使用者的瀏覽習慣。即使用HTTPS加密傳輸，ISP仍然能夠透過DNS請求瞭解使用者的造訪記錄。

DNS over HTTPS（DoH）：解決方案還是新的問題？

為瞭解決DNS請求的隱私問題，DNS over HTTPS（DoH）技術應運而生。DoH透過將DNS請求加密並透過HTTPS傳輸，旨在防止ISP監控使用者的DNS請求。然而，這種做法並未真正解決隱私問題，反而將監控權集中到了大型科技公司（如Google和Apple）手中。

DoH的運作原理與影響

DoH使用集中式的DNS解析器，取代了原本由ISP提供的DNS伺服器。這意味著DNS請求不再經過ISP，而是直接傳送到指定的DoH伺服器。雖然這在一定程度上保護了使用者的隱私，但也帶來了新的問題：

  1. 集中化風險：DoH將DNS請求集中到少數大型科技公司，可能導致這些公司擁有過多的使用者資料。
  2. 效能影響：DoH通常使用TCP傳輸，相比傳統的UDP傳輸的DNS請求，效能較差，可能導致解析速度變慢。
  3. 資源消耗增加：由於DoH需要進行額外的加密和解密處理，對系統資源的消耗較大。

電子郵件安全：加密的重要性

除了DNS請求外，電子郵件傳輸也面臨著類別似的安全隱患。常見的電子郵件傳輸協定，如SMTP、POP3和IMAP，預設情況下並未進行加密，這使得攻擊者能夠輕易地攔截和閱讀電子郵件內容。

電子郵件加密技術

為了提升電子郵件的安全性，可以採用SSL/TLS加密技術來保護電子郵件的傳輸過程。透過在SMTP、POP3和IMAP上新增加密層，可以有效防止攻擊者攔截和閱讀電子郵件內容。

資料傳輸的安全考量：有線與無線網路

資料在傳輸過程中的安全性不僅取決於加密技術，還與傳輸媒介有關。有線網路傳輸通常比無線網路更安全，因為無線網路的訊號可以被輕易攔截。

無線網路的安全挑戰

無線網路（如WiFi和行動資料）使用無線電波進行通訊，這使得攻擊者能夠在不接觸實體裝置的情況下攔截資料。雖然無線網路傳輸可以採用加密技術（如WPA3）來保護資料，但攻擊者仍可能透過破解加密或利用其他漏洞來取得資料。

資料保護：靜態與傳輸中的資料

除了傳輸過程中的資料安全外，靜態資料（如儲存在硬碟、USB裝置或備份媒體中的資料）也需要適當的保護措施。對於儲存在實體媒體上的資料，加密是確保資料安全的關鍵。

靜態資料的加密保護

為了保護靜態資料，可以採用磁碟加密、檔案加密等技術。這些技術能夠確保即使實體媒體被竊取，資料仍然保持安全。

內容解密：

此圖表詳細展示了DNS解析過程和電子郵件傳輸的安全機制。首先，使用者發出網址請求後，系統會進行DNS解析。傳統的DNS解析過程涉及向ISP的DNS伺服器傳送請求，而DoH則將請求傳送到指定的DoH伺服器，並透過HTTPS加密傳輸。在電子郵件傳輸方面，SMTP、POP3和IMAP協定可以用SSL/TLS加密來保護資料安全。這些機制共同構成了網際網路通訊的安全基礎。

網路安全

隨著網際網路技術的不斷進步，網路安全面臨的挑戰也日益增加。未來，我們需要進一步提升加密技術、改進安全協定，並加強對新型攻擊手段的防禦能力。同時，使用者也需要提高安全意識，採取適當的安全措施來保護自己的資料和隱私。

import ssl
import socket

def create_secure_connection(host, port):
    context = ssl.create_default_context()
    with socket.create_connection((host, port)) as sock:
        with context.wrap_socket(sock, server_hostname=host) as ssock:
            return ssock

# 使用範例
secure_sock = create_secure_connection('example.com', 443)
print(secure_sock.version())

內容解密：

此Python程式碼範例展示瞭如何使用SSL/TLS建立安全的網路連線。首先，透過ssl.create_default_context()建立一個預設的SSL上下文。然後，使用socket.create_connection()建立到指定主機和埠的連線。最後，透過context.wrap_socket()將連線包裝為安全的SSL/TLS連線。這個範例展示瞭如何在Python中實作安全的網路通訊。

網路安全最佳實踐

為了確保網際網路的安全性，我們需要採取一系列的最佳實踐措施，包括但不限於：

  1. 使用HTTPS：確保網站和服務使用HTTPS加密傳輸資料。
  2. 實施DoH：採用DNS over HTTPS來保護DNS請求的隱私。
  3. 電子郵件加密：使用SSL/TLS加密電子郵件傳輸。
  4. 無線網路安全：採用WPA3等安全協定保護無線網路。
  5. 靜態資料加密：對儲存在實體媒體上的資料進行加密保護。

透過這些措施，我們可以有效提升網際網路的安全性，保護使用者的隱私和資料安全。

玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。