Akamai Site Shieldの更新をGithub Actionsを利用してLinode Firewallへ自動的に適用する

# Akamai Site Shiled とは

Site Shieldはアカマイが提供するオリジンWebサーバーの保護機能です。アカマイWAFなどのクラウドベースのセキュリティ保護機能を常に適用するには、セキュリティ保護機能をバイパスしてオリジンサーバーに直接攻撃者のアクセスが到達しないように防御するしくみが必要です。クライアントがオリジンに直接アクセスすることを禁止し、Akamai Intelligent Edge Platformを経由したウェブトラフィックのみが通過できるよう、オリジンの手前に設置したレイヤ3/4ファイアウォールで制御すれば、オリジンは、各種のセキュリティ対策で検査されたリクエストのみを受け取れるようになります。

Site Shieldはオリジンサーバーとの通信を行うAkamai Edgeサーバーを限定する機能です。(Site Shield サーバーのソースIPのみをオリジン側の許可リストに登録することで、バイパスを防止するアクセス制御を可能とします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/49877/69684aad-7dfc-4992-d523-019392ba879d.png)

# Akamai Site Shieldの更新をGitHub Actionsを利用してLinode Firewallへ自動的に適用する

Site Shieldでオリジンサーバーにアクセスを行うIPアドレスのレンジは定期的に追加や削除が行われます。そのため運用の際には、Firewallに設定しているアクセスリストの更新も必要となります。

今回はこのSite Shieldの更新作業をGitHub Actionsを利用して、Linode Firewallに自動適用してみます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/49877/a190eae1-059d-d76c-abac-988d58e367ed.png)


手動にてSite Shieldの更新を行う場合の手順はこちらです。


**参考：[Site Shieldの設定方法と確認(運用・更新編)](https://community.akamai.com/customers/s/article/JapanUserGroupSiteShield20190627090957?language=en_US)**

:::note warn
執筆時点でNodeBalancerにFirewallは適用できないため、インスタンスへの通信保護としてのFirewallの利用を前提としております。
:::


## GitHub Actions とは

GitHub Actionsは、GitHubが提供するCI/CDのためのワークフローエンジンです。 ワークフローエンジンは、ビルド、テスト、デプロイといったCI/CD関連のワークフローを実行し、定期実行するワークフローを管理するなど、開発におけるソフトウェア実行の自動化を行います。
Linux、 macOS、 Windowsおよびコンテナに対応しており、プロジェクトを簡単にビルドおよびテストできます。 

**参考:[GitHub Actions - アイデアからリリースまでのワークフローを自動化](https://github.co.jp/features/actions)**


## SS2LF ・ SiteShield to LinodeFirewall

作成したGitHub Actionsのワークフローはこちらになります。

https://github.com/isss802/ss2lf

動作の参考としたい場合には、部分的にコピーもしくは、Forkして利用することができます。

:::note warn
ss2lfはMITライセンスです。著作者はソフトウェアの動作を保証することはなく、結果について責任を一切負いません。
:::

## Secretの設定


利用する際には、Actions secretsを設定します。

- AKAMAI_CREDENTIALS : Akamai CLIに利用するCredentials
- MAP_ID：対象のSite Shield MapのID
- LINODE_CLI_TOKEN：Linode CLIに利用するToken
- FIREWALL_ID：IPを適用するFirewallのID

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/49877/b7672a12-add4-5ef5-2566-765e6edcb4d8.png)

### AKAMAI_CREDENTIALS

```yaml
[default]
client_secret = 
host = akab-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.luna.akamaiapis.net
access_token = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
client_token = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
```

**取得方法 : [Akamai Control Centerで APIクレデンシャルを作成する](https://qiita.com/kabe-akam/items/499507d19220b44b4901)**

### MAP_ID
```yaml
[7桁の数字]
```

```yaml
# Akamai CLIでの確認

akamai site-shield --section default list-maps
```

### LINODE_CLI_TOKEN
```yaml
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
```

**取得方法 : [create-an-api-token](https://www.linode.com/docs/guides/getting-started-with-the-linode-api/#create-an-api-token)**

### FIREWALL_ID
```yaml
[5桁の数字]
```

```yaml
# Linode CLIでの確認

linode-cli firewalls list
```

## 実行時の注意点

ss2lfでは自動的にSite Shieldの適用完了まで行います。
初回にて動作確認等を行いたい場合には、該当の処理を外して実行し、実行結果が問題ないことを確認してから運用に乗せることをお勧めします。

```yaml
    # 新しいIP Listを使えるようにSite ShieldのAck処理をする
    - name: Update acknowledged
      run: |
        ./akamai site-shield --section default acknowledge --map-id $MAP_ID
      if: steps.ack.outcome == 'failure' && steps.diff.outcome == 'failure'
```

## Actionの実行

実際に利用する際には、定期実行にすることで更新のチェックを自動化することができます。
ss2lfでは手動で実行するようにしています。

```yaml
# 手動の場合
on:
  workflow_dispatch:

# Cronの場合
on:
  schedule:
    - cron:  '0 * * * *'
```

参考：**[Github Actions Schedule](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule)**

手動にて実行する場合には、Actionsから:Run Workflow:で行います。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/49877/c16ebc6f-722f-1076-87b2-1366ff938c69.png)

# まとめ

GitHub Actionsを利用することで、自前でサーバー等も用意せず簡単に自動化するワークフローを組むことができます。
AkamaiとLinodeではAPIやCLIを提供しており、様々なワークフローに対応した処理を行うことができます。

# 関連記事

アカマイ・テクノロジーズ合同会社のQiitaではLinode関連など開発者向けの記事を記載しております。

https://qiita.com/organizations/Akamai