ALB経由でWindows認証をしたら起きたこと

目的

お客様環境でALB経由でADFS(Active Directory Federation Service)での証明書Web登録を行っており、証明書Web登録にはWindows認証を経る必要があるのですが、その際に思わぬ想定外の事態が発生しました。これはALBとWindows認証の相性が悪いことに起因する不具合です。

そこでその起きてしまった事象を教訓とし、アイレット社内での知見として共有して広めておき、再発防止を強化する目的で、今回奇遇にもインシデントを通してセキュリティに関する注意点や、対策を共有するインシデント供養祭という場を与えられたため、LTとして発表してみようと思いました。

今回の事象はセキュリティインシデントと言うと少し大袈裟かもしれませんが、情報も少なく、ぜひ共有しておきたいノウハウとなります。

アジェンダ

  1. 起きた事象
  2. 事象の再現方法
  3. 原因及び対策
  4. 改善策
  5. まとめ

(予備知識)Windows認証とは

(統合)Windows認証とは、Active Directoryのユーザーアカウントを使用して接続先サービスにて認証するIISの機能です。あるWebサイト配下の特定のパスに対して認証を要求するように設定します。IISサーバーとアクセスするWindowsクライアントの双方が同じADドメイン環境配下に存在している場合は、手動でのユーザー情報の入力をする必要がないこと以外は、基本(Basic)認証と同じです。

制限事項として、以下の2点があります。

  • 通信経路上にHTTPプロキシが存在している場合は利用できません。
  • Microsoft 社のソフトウェア間でのみ実装可能となっています。

ネットワーク構成

  1. ADFSにIIS+ADCS(+証明機関Web登録)サービスをインストール
  2. test01ユーザーはALB経由でIISのページ(https://〜/certsrv)にアクセスする時に、ADを通してWindows認証を受ける
  3. その後、test01用のクライアント証明書が発行される

このとき、何が起きたか?

この証明書発行サービスの運用が一部ユーザーに本格稼働してから数日後、お客様から次のような報告が寄せられました。

利用者から「発行したユーザーIDとは異なるユーザーの証明書がインストールされている」との問い合わせを受けております。ユーザーID test01のユーザーに、test02の証明書がインストールされています。
現象が発生したユーザーに状況をヒアリングしたところ、「異なる2つのPCに同一ユーザーIDの証明書を発行、インストールしようとしていたところ、発行先が異なるIDのものがインストールされた。」という情報も得ました。
複数のユーザーから同様の問い合わせを受けております。

つまり、他人のクライアント証明書が誤発行されている!
例えば、test02ユーザーに対して発行されてはいけないtest01のクライアント証明書が発行されてしまっているということ。

事象再現

  1. 利用者test-01がnozaki-bastionでtest01ユーザーでcertsrvにログインしておく
  2. 利用者test-02がnozaki-WAPでブラウザのキャッシュ等全て削除しておき、1.のあとアイドルタイムアウトの60秒以内にcertsrvにアクセスする
  3. Windows認証が出るが、無視してリロードを繰り返す
  4. やがて認証なしで証明書を発行できるようになるので、証明書を発行する
  5. するとnozaki-WAPのブラウザで、ユーザーtest02にtest01ユーザー用の証明書が発行される

ちなみにALBを介していないIISで同様の方法を試しましたが、こちらは再現しませんでした。

原因とその対策方法(参考になったサイト)

ALBではプロキシサーバみたいな動きをします。ターゲットインスタンスへ接続情報を渡す際に、IPアドレスなどがALBとなります。そのためWebサーバは「こっちで持っているユーザ情報と一致しない」状況となってしまいます。仮に接続出来たとしても「ALBさんいらっしゃい」と全ユーザ共通で出てしまうのです。

  • Windows Authentication fails with AWS Application ELB」

(翻訳)
ALBを構成しているときに、Windows認証に関連する奇妙な問題に遭遇しました。HTTPリスナーで構成された内部ALBを経由すると、ターゲットWebサーバー (IIS) は常に資格情報の入力を要求し、正しい資格情報を受け入れず、ログオンの問題が発生したり、他のユーザーのセッションに接続したりすることがありました。いくつかの調査の後、最初に使用したALBの代わりに新しいNLBを作成したところ、機能し始めました。

Windows認証 (Kerberos または NTLM フォールバック) では、認証を維持するためにTCP接続が同じ送信元ポートを維持する必要があります。これはHTTPでは発生せず、ブラウザが送信元ポートを切り替えると、新しいTCPセッションが作成され、古いポートを介してWebサーバーにプロキシされ、認証が無効になります。これは、レイヤ4の「ネットワーク」ロードバランサーでは発生しません。レイヤ7の「アプリケーション」ロードバランサーを介したWindows認証はできません

(翻訳)
Windows認証では、クライアントからサーバーへの接続で送信元ポートが保持される必要がありますTCP リスナーを備えたNLBは、負荷分散された接続の送信元ポートを保持します。このため、Windows認証を使用する場合は、NLBを使用してください

改善できるところがあるとすれば

  • ALBはプロキシのような動作をするので、ALBを選定する際、その送信元IPアドレスとポート番号が変わる動作が既存の構成に支障を与えないかもう少し配慮しておく必要があった。
  • 今回検証段階でWindows認証が無事通ってしまい、ALBのプロキシ動作がたまたま悪さをしなかったために、この不具合に気付くことができなかった。
  • ALBとWindows認証の相性の悪さを伝えている日本語のサイトが1つか2つくらいしかヒットしなかった。AWSの公式ドキュメントは、「ALB Windows Authentication」と英語だけで検索すればヒットした。AWSの公式docsはまだまだ英語のみの情報が多いため、英語キーワードだけで検索する癖を付けておきたい。

まとめ

  • Windows認証では、TCP接続が同じ送信元ポートを維持する必要がある
  • Windows認証は、HTTPプロキシと相性が悪い
  • ALBはプロキシサーバのような動作をする
  • ALBを経由してWindows認証を行うと、正しい資格情報でログオンできなかったり、他のユーザーのセッションに接続したりする
  • レイヤ7のALBを介したWindows認証はできない
  • NLBは、送信元ポート番号を保持するため、Windows認証を使用する場合はNLBを使用する
  • ALBを使うなら、今ならALBの相互認証(mTLS)によるクライアント証明書認証を使うという手も

GuardDutyでECS on Fargateでランタイムセキュリティの脅威を検出してみた

目的・やりたいこと

Amazon GuardDuty の新機能、Amazon ECS および AWS Fargate でランタイムセキュリティの脅威を検出
コンテナのリスク対策にはこれまでEKS Runtime Monitoringなどがあったが、Fargateにはなかった。
今回のアップデートによって、ECS on Fargateでもコンテナのリスクへの対応が可能に

AWSサービス ECS on Fargate ECS on EC2 EKS on Fargate EKS on EC2
GuardDuty Runtime Monitoring ⭕️(今回の対象) △(プレビュー) ×
GuardDuty Malware Protection × ×

そこでECS on Fargateを対象とし、ランタイムセキュリティの脅威を検出する検証をしてみた。
ただ検知させるだけならいくらでも参考ブログはありますが、そこに至る過程でかなり苦労したので、他では省略されているその苦労をありのままに記載することで、初心者がECS on Fargateでランタイムセキュリティの脅威を検出できるようになることへの一助になればと思います。

対象者

ECS on Fargateでランタイムセキュリティの脅威を検出してみたい初心者

対象となる技術

  • GuardDuty(ランタイムモニタリング)
  • ECS on Fargate

条件(導入にあたっての前提事項)

  • 今回使用したタスクロール「ecsTaskExecutionRoke」にはあらかじめ必要な権限やポリシーが付与されているものとします。

参考URL

概要図

作業の流れ

事前作業

1.まずはこちらのハンズオンに従ってECS on Fargateを構築

dockerコンテナの確認

cloudpack-federation-admin:~/environment $ docker ps
CONTAINER ID   IMAGE         COMMAND                  CREATED             STATUS             PORTS                                   NAMES
8ea9c3a5c1cb   hello-world   "/bin/sh -c /root/ru…"   About an hour ago   Up About an hour   0.0.0.0:8080->80/tcp, :::8080->80/tcp   h4b-local-run

cloudpack-federation-admin:~/environment $ docker exec -it h4b-local-run /bin/bash              
root@8ea9c3a5c1cb:/# 

2.次にこちらの手順に従い、GuardDuty ECS Runtime Monitoringを有効化

ところが、[ランタイムカバレッジ]タブで[ECSクラスターのランタイムカバレッジ]欄を見ると、カバレッジステータスが「Unhealthy」に

「1個の問題を表示」をクリックしても、タスクに問題がありそうというくらいしかわからない

そもそもタスクのヘルスステータスが「不明」なのが問題


ヘルスステータスの詳細を見ると、「タスク内の重要なコンテナのヘルスチェックがまだ評価されているか、コンテナのヘルスチェックが定義されていません。」とのこと

と思ったが、タイムラグがあるだけで時間が経つとちゃんと認識してくれた。

これでひとまず準備は完了

検証手順

1.コンテナにログイン

cloudpack-federation-admin:~/environment $ docker exec -it h4b-local-run /bin/bash
Error response from daemon: Container 8ea9c3a5c1cbab2f094954a88aaca8ca5e4924db4c9bfb6a84f0b537ea7a6fd0 is not running
cloudpack-federation-admin:~/environment $ docker ps -a
CONTAINER ID   IMAGE         COMMAND                  CREATED        STATUS                     PORTS     NAMES
8ea9c3a5c1cb   hello-world   "/bin/sh -c /root/ru…"   23 hours ago   Exited (137) 9 hours ago             h4b-local-run
cloudpack-federation-admin:~/environment $ docker start 8ea9c3a5c1cb
8ea9c3a5c1cb
cloudpack-federation-admin:~/environment $ docker exec -it h4b-local-run /bin/bash
root@8ea9c3a5c1cb:/# 

コンテナが停止していたので再実行しました。

2.GuradDutyが検知してくれそうなコマンドを実行
ここでGuardDutyが検知してくれて、かつ安全無害なコマンドを実行しないといけません。検証環境といえども
候補は二つあります。

  • nslookup guarddutyc2activityb.com

公式に記載されているあらかじめ用意されているテスト用のドメイン

GuardDuty がこの検出タイプ(バックドア:EC2/C&CActivity.B!DNS)をどのように生成するかをテストするには、インスタンス ( Linuxの場合dig、Windows の場合をnslookupを使用) からテストドメインguarddutyc2activityb.comに対してDNSリクエストを作成できます。

  • nslookup pool.supportxmr.com

こちらのブログに記載のあるCryptoCurrency:EC2/BitcoinTool.B!DNSを検知してくれるドメイン

このドメインはモネロのマイニングプールの1つです。一応これ自体は正規なものなのでアクセスしても大丈夫だと思います。

これら二つともコンテナ上で実行してみる。nslookupするだけなので害はない。

cloudpack-federation-admin:~/environment $ docker exec -it h4b-local-run /bin/bash
root@8ea9c3a5c1cb:/# nslookup guarddutyc2activityb.com
Server:         10.0.0.2
Address:        10.0.0.2#53

Non-authoritative answer:
*** Can't find guarddutyc2activityb.com: No answer

root@8ea9c3a5c1cb:/# nslookup pool.supportxmr.com
Server:         10.0.0.2
Address:        10.0.0.2#53

Non-authoritative answer:
pool.supportxmr.com     canonical name = pool-hk.supportxmr.com.
Name:   pool-hk.supportxmr.com
Address: 139.99.124.170
Name:   pool-hk.supportxmr.com
Address: 139.99.125.38
Name:   pool-hk.supportxmr.com
Address: 139.99.123.196

前者は見つからなくて正解、後者はちゃんと回答がある。

3.GuardDutyの検出結果を確認


ご覧のように一応検知はしてくれているが、検出結果タイプに「EC2」、リソースも「Instance」になっている。これではECS on EC2によるEC2セキュリティの検知であって、今回の対象であるECS on Fargateによるランタイムセキュリティの検知ではない。

どうも調べてみると、今回の意図した結果を得るには、コンテナにシェルログイン(起動したECSタスクにECS Execでログイン)してコマンドを実行する必要があるらしい。

4.ECS Execの設定
そこで、公式ドキュメントUsing Amazon ECS Exec for debuggingに従い、ECS Execを実装します。
ところが、「Turning on ECS Exec for your tasks and services」に記載のコマンドを実行してもエラーが

cloudpack-federation-admin:~/environment $ aws ecs create-service \
>     --cluster h4b-ecs-cluster \
>     --task-definition arn:aws:ecs:ap-northeast-1:************:task-definition/h4b-ecs-task-definition:16 \
>     --enable-execute-command \
>     --service-name h4b-ecs-service2 \
>     --desired-count 1

An error occurred (InvalidParameterException) when calling the CreateService operation: The service couldn't be created because a valid taskRoleArn is not being used. Specify a valid task role in your task definition and try again.

これはECS integration sets TaskRoleArn: null, doesn't work with ECS Exec #2120のCodaBoolさんのコメント通りにやることでうまくいきました。単にタスク定義で「タスクロール」を設定すればよかったらしい。


タスクロールはデフォルトでは「なし」になっているので、ここでは下のタスク実行ロールと同じロールを付与。

再度チャレンジ

cloudpack-federation-admin:~/environment $ aws ecs update-service \
>     --cluster h4b-ecs-cluster \
>     --task-definition arn:aws:ecs:ap-northeast-1:************:task-definition/h4b-ecs-task-definition:17 \
>     --enable-execute-command \
>     --service h4b-ecs-service \
>     --desired-count 1 \
>     --force-new-deployment
{
    "service": {
        "serviceArn": "arn:aws:ecs:ap-northeast-1:************:service/h4b-ecs-cluster/h4b-ecs-service",
        "serviceName": "h4b-ecs-service",
        "clusterArn": "arn:aws:ecs:ap-northeast-1:************:cluster/h4b-ecs-cluster",
        "loadBalancers": [
〜略〜

5.念願のExecログイン!

cloudpack-federation-admin:~/environment $ aws ecs list-tasks --cluster h4b-ecs-cluster
{
    "taskArns": [
        "arn:aws:ecs:ap-northeast-1:************:task/h4b-ecs-cluster/0a5f2c7ef29947c3ab2c01cb8f477237"
    ]
}
cloudpack-federation-admin:~/environment $ aws ecs execute-command --cluster h4b-ecs-cluster \
>     --task 0a5f2c7ef29947c3ab2c01cb8f477237 \
>     --container apache-helloworld \
>     --interactive \
>     --command "/bin/sh"

The Session Manager plugin was installed successfully. Use the AWS CLI to start a session.


Starting session with SessionId: ecs-execute-command-0b66d5e4f32d71eda
# 

6.再度検知コマンドを実行

# nslookup pool.supportxmr.com
Server:         10.0.0.2
Address:        10.0.0.2#53

Non-authoritative answer:
pool.supportxmr.com     canonical name = pool-hk.supportxmr.com.
Name:   pool-hk.supportxmr.com
Address: 139.99.124.170
Name:   pool-hk.supportxmr.com
Address: 139.99.123.196
Name:   pool-hk.supportxmr.com
Address: 139.99.125.38

# nslookup guarddutyc2activityb.com
Server:         10.0.0.2
Address:        10.0.0.2#53

Non-authoritative answer:
*** Can't find guarddutyc2activityb.com: No answer

7.再度GuardDutyの検出結果を確認


検出結果に「Runtime」、リソースに「ECScluster」が入っていて意図通りの検知結果が得られました!

さらに詳細を見ると、EC2タイプには見られなかった「Containers」「ランタイムの詳細」という項目があります。

Eicarを検知できるか検証

Eicarの実行も検知できました!

# wget https://files.trendmicro.com/products/eicar-file/eicar.com
--2023-12-12 04:16:02--  https://files.trendmicro.com/products/eicar-file/eicar.com
Resolving files.trendmicro.com (files.trendmicro.com)... 23.37.117.19, 2600:140b:400:29a::1e79, 2600:140b:400:2b8::1e79
Connecting to files.trendmicro.com (files.trendmicro.com)|23.37.117.19|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 68 [application/octet-stream]
Saving to: ‘eicar.com’

eicar.com                                           100%[================================================================================================================>]      68  --.-KB/s    in 0s      

2023-12-12 04:16:02 (7.58 MB/s) - ‘eicar.com’ saved [68/68]

# ls
bin  boot  dev  eicar.com  etc  home  lib  lib64  managed-agents  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
# more eicar.com
(Eicarのコードなので念のためマスクしておきます)
# chmod +x eicar.com
# ./eicar.com
./eicar.com: 1: ./eicar.com: Syntax error: word unexpected (expecting ")")

Execution:Runtime/NewBinaryExecuted
コンテナで新しく作成、または最近変更されたバイナリファイルが実行されました。
デフォルトの重要度: Medium

機能: Runtime Monitoring

この検出結果から、コンテナ内で新たに作成、または変更されたバイナリファイルが実行されたことがわかります。実行時にコンテナを不変に保つことがベストプラクティスであり、バイナリファイル、スクリプト、またはライブラリはコンテナの存続期間中に作成または変更しないでください。新しく作成されたバイナリがコンテナ環境で実行されたことは非常に疑わしい状況です。この動作は、悪意のある攻撃者がワークロードにアクセスし、潜在的な侵害の一環としてマルウェアやその他のソフトウェアをダウンロードして実行したことを示しています。

所要時間

2時間

まとめ

今回のアップデートによって、GuardDutyでもECS on Fargateコンテナのランタイムセキュリティが検知できるようになりました。残るEKS on Fargateに対しても対応できるようになれば、コンテナ対策という意味では完璧ですね!更なるアップデートに期待です。
参考までに、GuradDuty、Prisma Cloud、Sysdigでのランタイム保護機能をECSで比較したものを載せておきます。

FSx for ONTAPでドメイン参加できなかったのでCIFSサーバーを立ててドメイン参加⇨ファイル共有までしてみた

サービス概要

FSx for NetApp ONTAPとは、NetAppのONTAPファイル システム技術に基づいて構築された信頼性の高い高性能のファイル ストレージを提供するAWSのフルマネージドファイル ストレージサービスです。

〔主な機能〕

  • 使い慣れた ONTAP 機能: オンプレミスの ONTAP 導入でお客様が得られる、スナップショット、クローン作成、レプリケーション、柔軟なストレージ管理などの機能を提供します。
  • ハイパフォーマンス: データベース、ホーム ディレクトリ、分析ワークロードなどの一般的なワークロードに、低遅延の SSD ベースのストレージを提供します。
  • シンプルな管理: ONTAP インフラストラクチャのプロビジョニング、構成、メンテナンスを処理するため、お客様はハードウェアの管理について心配する必要がありません。
  • セキュリティとアクセス制御: ID とアクセス管理のためのAD統合をサポートしています。また、保存中および転送中のデータの暗号化も提供します。
  • バックアップと災害復旧: 災害復旧のための信頼性の高いバックアップ、復元、リージョン間のレプリケーション機能を提供します。

目的・やりたいこと

〔調査事項〕

  1. ADの設定でフォルダに対するアクセス権限が付与できるか?
  2. ADで定義したグループ単位でアクセス権限が付与できるか?
  3. フォルダに対するアクセス権限の設定方法
  4. GUIで設定可能か?
  5. 設定ファイルのインポートなどで、一括で設定することは可能か?
  6. シャドウコピーと同等の機能はONTAPにもあるか?
  7. フォルダ単位のクォータに対して、下記のようなことは実現可能か?
    ・クォータの消費率に対して、閾値を設けてのアラート送信
    ・フォルダごとのクォータ消費率の出力

  8. フォルダ毎のクォータの消費率を確認する方法

  9. 監査ログを閲覧する方法  S3やCloudWatchに転送する設定はなかったかと思うので、ONTAP管理画面かWindows Serverから確認する形になるかと思いますが、具体的な確認方法が分からず。
  10. 監査ログは「過去1年間保存、直近3ヶ月分は即調査可能な状態にする」と要件があります。1年後にログを削除するような設定はあるか?

対象となる技術

  • FSx for NetApp ONTAP

条件(導入にあたっての前提事項)

  • パブリックサブネットに置いた踏み台用Windows、プライベートサブネットのManaged ADはあらかじめ作成済みとします。

参考URL

注意事項

概要図

作業の流れ

事前作業

まずはFSx for ONTAPを構築します。

1.[ファイルシステムを作成]

2.[Amazon FSx for NetApp ONTAP]を選択

3.スタンダード作成で以下のように入力

4.デフォルトのストレージ仮想マシン設定で以下のように入力

5.デフォルトのボリューム設定で以下のように入力

6.それ以外はデフォルトでOKで、確認および作成
「作成後に編集可能」が❌になっているものに注意して[ファイルシステムを作成]

7.[ファイルシステム][ボリューム][ストレージ仮想マシン(SVM)]のステータスを確認
ところがSVMで設定ミス

エラーメッセージを翻訳すると以下ということらしい。

受け取ったエラーメッセージは、Amazon FSx が Active Directory との接続を確立できないことを示しています。これは、ポート要件が満たされていないこと、または提供されたサービス アカウントの権限が不十分であることが原因である可能性があります。
この問題を解決するには、まず、Amazon FSx ドキュメントに記載されているポート要件が満たされていることを確認します。ネットワークと FSx の間でポート 389、3268 ~ 3269、88、135、445、および 464 が開いていることを確認します。
次に、サービス アカウントに必要な権限があることを確認します。このアカウントには、指定された組織単位(OU)を持つドメインにストレージ仮想マシンSVM)を参加させるための権限が必要です。
最後に、ポート要件とサービス アカウント権限をチェックアウトする場合は、SVM への参加時に指定した OU が存在し、アクセス可能であることを再確認します。

ところが、ADのSG「d-956752b702_controllers」では、このようにデフォルトで必要なポートがあらかじめ全部空いている。


一応FSxのSGもデフォルトのものに色々付け足しておいたが、それでも通らない。

そこで、参考サイトを参考にこのように設定してみた。


ポイントは、NetBIOS名が今まで「nozaki2」にしてたんだが、それだとドメインの一部だからダメということで怒られたので、適当な名前に
あとはOUを「OU=Computers, OU=nozaki2, DC=nozaki2, DC=com」のように指定してみたら通った!OUってオプション項目なのに実は必須だったという酷さ・・

8.この状態で[ADに参加/更新]でnozaki2.comをリトライ。あっさり「作成済み」に

ADから見ても、ComputersにAAAとNOZAKI2がいるのを確認

9.踏み台からfsmgmt.mscコマンドを使ってONTAPを共有してみる

ところがここでまたしてもエラー

そうこうして何度もONTAPを再作成しているうちに、またもやドメインに参加できない事態に・・なぜか奇跡的にドメインに参加できた上記↑が再現できない

なのでここで方針転換。WORKGROUPに所属するCIFSサーバーを立てて、マウントしてみることにする。

1.踏み台からFSx for ONTAPファイルシステムSSHで接続

$ ssh fsxadmin@management.fs-06cf2b480cb59b9f6.fsx.ap-northeast-1.amazonaws.com
Password:

This is your first recorded login.
Unsuccessful login attempts since last login: 2
Your privilege has changed since last login.

ここでホスト名は、ファイルシステムの管理エンドポイントのDNS名参照

2.CIFSサーバーの作成

FsxId06cf2b480cb59b9f6::> vserver cifs create -vserver nozakiSVM -cifs-server cifs-server -workgroup fsxn-workgroup

Notice: SMB1 protocol version is obsolete and considered insecure. Therefore it is deprecated and disabled on this CIFS server. Support for SMB1 might be removed in a future
release. If required, use the (privilege: advanced) "vserver cifs options modify -vserver nozakiSVM -smb1-enabled true" to enable it.

FsxId06cf2b480cb59b9f6::> vserver cifs show
            Server          Status    Domain/Workgroup Authentication
Vserver     Name            Admin     Name             Style
----------- --------------- --------- ---------------- --------------
nozakiSVM   CIFS-SERVER     up        FSXN-WORKGROUP   workgroup

「CIFS-SERVER」というCIFSサーバーを立てました。

3.CIFSユーザーの作成

FsxId06cf2b480cb59b9f6::> vserver cifs users-and-groups local-user create -vserver nozakiSVM -user-name nozaki -is-account-disabled false

Enter the password:
Confirm the password:

FsxId06cf2b480cb59b9f6::> vserver cifs users-and-groups local-user show -instance

                                   Vserver: nozakiSVM
                                 User Name: CIFS-SERVER\Administrator
                                 Full Name:
                               Description: Built-in administrator account
                       Is Account Disabled: true

                                   Vserver: nozakiSVM
                                 User Name: CIFS-SERVER\nozaki
                                 Full Name: -
                               Description: -
                       Is Account Disabled: false
2 entries were displayed.

「CIFS-SERVER\nozaki」というCIFSユーザーを作成しました。

4.CIFSファイル共有の作成

FsxId06cf2b480cb59b9f6::> volume show
Vserver   Volume       Aggregate    State      Type       Size  Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
nozakiSVM nozakiSVM_root
                       aggr1        online     RW          1GB    972.0MB    0%
nozakiSVM vol1         aggr1        online     RW          1TB    860.5GB    0%
2 entries were displayed.

FsxId06cf2b480cb59b9f6::> volume show -fields junction-path
vserver   volume         junction-path
--------- -------------- -------------
nozakiSVM nozakiSVM_root /
nozakiSVM vol1           /vol1
2 entries were displayed.

FsxId06cf2b480cb59b9f6::> vserver cifs share create -vserver nozakiSVM -share-name cifs-share -path /vol1

FsxId06cf2b480cb59b9f6::> vserver cifs share show -vserver nozakiSVM
Vserver        Share         Path              Properties Comment  ACL
-------------- ------------- ----------------- ---------- -------- -----------
nozakiSVM      c$            /                 oplocks    -        BUILTIN\Administrators / Full Control
                                               browsable
                                               changenotify
                                               show-previous-versions
nozakiSVM      cifs-share    /vol1             oplocks    -        Everyone / Full Control
                                               browsable
                                               changenotify
                                               show-previous-versions
nozakiSVM      ipc$          /                 browsable  -        -
3 entries were displayed.

vol1に「cifs-share」というファイル共有を作成しました。

5.踏み台のPowershellを使って、CIFSユーザーの認証情報でSMBでZドライブにボリュームをマウント

PS C:\Users\Administrator> net use Z: \\10.0.13.3\cifs-share
\\10.0.13.3\cifs-share のパスワードが無効です。

'10.0.13.3' のユーザー名を入力してください: CIFS-SERVER\nozaki
10.0.13.3 のパスワードを入力してください:
コマンドは正常に終了しました。

ここではSVMの以下のIPを使ってアクセスしました。

また、共有名は「cifs-share」、ユーザー名は「CIFS-SERVER\nozaki」になることに注意。

6.マウントできていることを確認

CIFSサーバーをドメインに参加させる手順

1.SVMが参照するDNSサーバーとして、ディレクトリサービス「nozaki.com」のDNSアドレスを指定

FsxId06cf2b480cb59b9f6::> dns create -vserver nozakiSVM -domains nozaki.com -name-servers 10.0.10.237

Warning: Only one DNS server is configured. Configure more than one DNS server to avoid a single-point-of-failure.

FsxId06cf2b480cb59b9f6::> dns show -instance

                        Vserver: nozakiSVM
                        Domains: nozaki.com
                   Name Servers: 10.0.10.237
                 Timeout (secs): 2
               Maximum Attempts: 1

FsxId06cf2b480cb59b9f6::> dns check -vserver nozakiSVM -name-server 10.0.10.237

           Vserver: nozakiSVM
       Name Server: 10.0.10.237
Name Server Status: up
    Status Details: Response time (msec): 0

2.ステータスをdownにしてCIFSサーバーをドメインに参加
と、ここでエラーが

FsxId06cf2b480cb59b9f6::> vserver cifs modify -vserver nozakiSVM -cifs-server CIFS-SERVER -domain nozaki.com -status-admin down

In order to create an Active Directory machine account for the CIFS server, you must supply the name and password of a Windows account with sufficient privileges to add
computers to the "CN=Computers" container within the "NOZAKI.COM" domain.

Enter the user name: Admin

Enter the password:

Error: Machine account creation procedure failed
  [  8140] Loaded the preliminary configuration.
  [  8154] Successfully connected to ip 10.0.10.237, port 88 using
           TCP
  [  8196] Successfully connected to ip 10.0.10.237, port 389 using
           TCP
**[  8209] FAILURE: Could not create account
**         'cn=CIFS-SERVER,CN=Computers,dc=NOZAKI,dc=COM': an LDAP
**         constraint violation occurred, which may indicate the
**         supplied user has insufficient privilege to add an
**         account in the specified organizational unit

Error: command failed: Failed to create the Active Directory machine account "CIFS-SERVER". Reason: LDAP Error: The user has insufficient access rights.

どうやらOUをちゃんと指定してなかったのが原因らしい。気を取り直して再チャレンジ

FsxId06cf2b480cb59b9f6::> vserver cifs modify -vserver nozakiSVM -cifs-server CIFS-SERVER -domain nozaki.com -status-admin down -ou ou=NOZAKI

In order to create an Active Directory machine account for the CIFS server, you must supply the name and password of a Windows account with sufficient privileges to add
computers to the "ou=NOZAKI" container within the "NOZAKI.COM" domain.

Enter the user name: Admin

Enter the password:

FsxId06cf2b480cb59b9f6::> vserver cifs show -instance

                                          Vserver: nozakiSVM
                         CIFS Server NetBIOS Name: CIFS-SERVER
                    NetBIOS Domain/Workgroup Name: NOZAKI
                      Fully Qualified Domain Name: NOZAKI.COM
                              Organizational Unit: ou=NOZAKI
Default Site Used by LIFs Without Site Membership:
                                   Workgroup Name: -
                             Authentication Style: domain
                CIFS Server Administrative Status: up
                          CIFS Server Description:
                          List of NetBIOS Aliases: -

祝・念願のドメイン参加成功!

3.CIFSサーバーが指定したOU「nozaki」上に作成されたことを確認

Get-ADComputer  -Filter "*" -SearchBase "DC=nozaki,DC=com"
〜略〜
DistinguishedName : CN=CIFS-SERVER,OU=nozaki,DC=nozaki,DC=com
DNSHostName       : CIFS-SERVER.NOZAKI.COM
Enabled           : True
Name              : CIFS-SERVER
ObjectClass       : computer
ObjectGUID        : 0cc3c66c-4065-47aa-9e2c-ea2a01765950
SamAccountName    : CIFS-SERVER$
SID               : S-1-5-21-1702849902-3745289662-1852962917-1202
UserPrincipalName :

最後の方にちゃんといました!
ところがこれがADのGUI上だとコンピュータが見れないし、AWSマネジメントコンソールからだとドメイン参加が確認できない。どうやら表示にかなりタイムラグがあるらしい。
しかしこれも30分ほど経つとようやく表示された!


こうして見ると「ou=NOZAKI」になってるな。そもそもドメインになかなか参加できなかったのはOUの指定が間違ってたのかもしれない。。
と思ったら、ADで見たら変な場所にCIFSコンピュータが作られていたので移動した。「ou=NOZAKI, ou=Computers」が正解だったのかも

SMB DNS名も表示されていることを確認

4.気を取り直してファイル共有にチャレンジ
ところがまたしても上記と同じエラー

そこで権限が足りないのだと思い、
ONTAP CLI を使用して SVM をアクティブディレクトリに接続する

この参加後に共有にアクセスできない場合は、共有にアクセスするために使用しているアカウントにアクセス許可が付与されていることを確認してください。例えば、 AWS マネージド Active Directory でデフォルトAdminアカウント (委任管理者) を使用している場合は、ONTAP で次のコマンドを実行する必要があります。netbios_domain は Active Directoryドメイン名に対応します (corp.example.com の場合、ここで使用される netbios_domain は example です)。

vserver cifs users-and-groups local-group add-members -vserver svm_name -group-name BUILTIN\Administrators -member-names netbios_domain\admin

を参考に、NOZAKI\Domain UsersをBUILTIN\Administratorsに入れてみました。

FsxId06cf2b480cb59b9f6::> cifs users-and-groups local-group show-members
Vserver        Group Name                   Members
-------------- ---------------------------- ------------------------
nozakiSVM      BUILTIN\Administrators       CIFS-SERVER\Administrator
                                            NOZAKI\Domain Admins
               BUILTIN\Guests               NOZAKI\Domain Guests
               BUILTIN\Users                NOZAKI\Domain Users
3 entries were displayed.

FsxId06cf2b480cb59b9f6::> cifs users-and-groups local-group add-members -vserver nozakiSVM -group-name BUILTIN\Administrators -member-names "NOZAKI\Domain Users"

FsxId06cf2b480cb59b9f6::> cifs users-and-groups local-group show-members
Vserver        Group Name                   Members
-------------- ---------------------------- ------------------------
nozakiSVM      BUILTIN\Administrators       CIFS-SERVER\Administrator
                                            NOZAKI\Domain Admins
                                            NOZAKI\Domain Users
               BUILTIN\Guests               NOZAKI\Domain Guests
               BUILTIN\Users                NOZAKI\Domain Users
3 entries were displayed.

5.ファイル共有再チャレンジ
さらに今度はSMB DNS名「CIFS-SERVER.NOZAKI.COM」ではなく、IP「10.0.13.3」直打ちでアクセスにし行く。
すると今度は共有一覧が普通に表示された!

新しい共有で「新しいフォルダー」を共有にしてみる

無事共有成功

手順

以降では課題を確認していく

1. ADの設定でフォルダに対するアクセス権限が付与できるか?
2. ADで定義したグループ単位でアクセス権限が付与できるか?
3. フォルダに対するアクセス権限の設定方法
4. GUIで設定可能か?


例えばこのようにDomain UsersというグループをGUIでフォルダに対してアクセス権をつけることができた。

5.設定ファイルのインポートなどで、一括で設定することは可能か?

この方法はなさそう。

6.シャドウコピーと同等の機能はONTAPにもあるか?

はい、スナップショット機能があります。
Working with snapshots
Snapshot ジョブスケジュールを作成

7.フォルダ単位のクォータに対して、下記のようなことは可能か?
・クォータの消費率に対して、閾値を設けてのアラート送信
・フォルダごとのクォータ消費率の出力

標準では、そのような細かいカスタマイズや設定は不可能です。
NetApp側の方でLambda関数を使用したFSx for ONTAPの監視方法のドキュメントが用意されていますので、ご活用ください。
・FSx for ONTAP の全体的なストレージ容量の使用状況
 各ボリュームの使用量(シンプロビジョニング/シックプロビジョニング)
・使用状況の警告やサイズ変更の通知をEメールで受信するアラートメカニズム

8.フォルダ毎のクォータの消費率を確認する方法

  • qtree(vol1の下にqtree1)を作成する
FsxId06cf2b480cb59b9f6::> volume qtree create -vserver nozakiSVM -qtree-path /vol/vol1/qtree1 -security-style ntfs
  • 「default」 policyに 1MB上限のクォータルールを作成する
 FsxId06cf2b480cb59b9f6::> volume quota policy rule create -vserver nozakiSVM -policy-name default -volume vol1 -type user -target "" -disk-limit 1MB -qtree qtree1
  • ボリュームに対してクォータを有効にする
FsxId06cf2b480cb59b9f6::> volume quota on -vserver nozakiSVM -volume vol1 -foreground true
[Job 57] Job is queued: "quota on" performed for quota policy "default" on volum
[Job 57] Running: sending quota rules. 1 quota rules sent.                      
[Job 57] Job succeeded: Successful

この状態で、例えば9.92MBあるファイルをqtree1下に移動しようとすると、1MB上限のクォータルールに抵触してエラーに

ここで課題、default以外のポリシーを作成するには?

あとはdefaultポリシーにどんどんルールを追加していけばいいだけなのですが、中には「default」という名前が嫌、複数のポリシーを作成できないの?という疑問を持つ方もいるかもしれません。
その辺りの仕様はこちら
クォータルール、クォータポリシー、およびクォータとは

1つのSVMに最大5つのクォータポリシーを保持できるため、クォータポリシーのバックアップコピーを保持できます。1つのSVMに割り当てられるクォータポリシーは常に1つです。

つまり、クォータポリシー自体は5つまで作成できるけど、実際にSVMに割り当てられるのは1つだけだよと。
実際にdefaultを削除して別のポリシー名を割り当てる方法はこちら
ONTAP FlexGroup ボリュームベストプラクティス/インプリメンテーションガイドのP124.「第9章 qtree 9.2 FlexGroupによるクォータの管理」

必要なポリシーを使用するには、SVMを変更し、クォータをオフにしてからオンに戻す必要があります。

cluster::*> vserver modify -vserver DEMO -quota-policy tree
cluster::*> quota off -vserver DEMO *
cluster::*> quota policy rule delete -vserver DEMO -policy-name default *
1 entry was deleted. 
cluster::*> quota on -vserver DEMO -volume flexgroup_local -foreground true
[Job 8084] Job succeeded: Successful
  • レポートの表示
FsxId06cf2b480cb59b9f6::> volume quota report
Vserver: nozakiSVM

                                    ----Disk----  ----Files-----   Quota
Volume   Tree      Type    ID        Used  Limit    Used   Limit   Specifier
-------  --------  ------  -------  -----  -----  ------  ------   ---------
vol1     qtree1    user    BUILTIN\Administrators
                                       0B      -       1       -
vol1     qtree1    user    CIFS-SERVER\nozaki
                                     32KB    1MB       4       -   *
vol1     qtree1    user    *           0B    1MB       0       -   *

ご覧のようになぜか1個しか表示されない。使用量はわかるが使用率の表示はなし
でもルールを見ると、他のQtreeに対してもちゃんとLimitは設定されている。

FsxId06cf2b480cb59b9f6::> volume quota policy rule show -policy-name default -volume vol1

Vserver: nozakiSVM         Policy: default           Volume: vol1

                                               Soft             Soft
                         User         Disk     Disk   Files    Files
Type   Target    Qtree   Mapping     Limit    Limit   Limit    Limit  Threshold
-----  --------  ------- -------  --------  -------  ------  -------  ---------
user   ""        aaa     off           2MB        -       -        -          -
user   ""        qtree1  off           1MB        -       -        -          -
user   ""        qtree2  off           2MB        -       -        -          -
user   ""        qtree3  off           1KB        -       -        -          -
user   ""        test    off           1MB        -       -        -          -
5 entries were displayed.

大幅な変更後のクォータの再初期化によると、クォータをレポートに反映させるには、クォータを設定する都度再初期化(volume quota設定のOFF⇨ON)が必要なようです。

FsxId06cf2b480cb59b9f6::> volume quota off -vserver nozakiSVM -volume vol1 -foreground true
[Job 80] Job succeeded: Successful

FsxId06cf2b480cb59b9f6::> volume quota on -vserver nozakiSVM -volume vol1 -foreground true
[Job 81] Job succeeded: Successful

FsxId06cf2b480cb59b9f6::> volume quota report
Vserver: nozakiSVM

                                    ----Disk----  ----Files-----   Quota
Volume   Tree      Type    ID        Used  Limit    Used   Limit   Specifier
-------  --------  ------  -------  -----  -----  ------  ------   ---------
nozakiSVM_root
         qtree3    user    BUILTIN\Administrators
                                       0B      -       1       -
nozakiSVM_root
         qtree4    user    BUILTIN\Administrators
                                       0B      -       1       -
nozakiSVM_root
         qtree3    user    *           0B    1GB       0       -   *
nozakiSVM_root
         qtree4    user    *           0B    1MB       0       -   *
vol1     qtree1    tree    1
                                   9.97MB    1GB       2       -   qtree1
vol1     aaa       tree    2
                                  19.96MB    1GB       5       -   aaa
vol1     qtree2    tree    3
                                  19.95MB    1GB       3       -   qtree2
vol1     qtree3    tree    4          8KB    1GB       2       -   qtree3
vol1               tree    *           0B    1GB       0       -   *
9 entries were displayed.

これで課題は使用率の表示だけに。ONTAP上でファイルやスクリプトを作成したりすることはできないのでどうするか。。
使えるコマンドはこれだけ。

FsxId06cf2b480cb59b9f6::>
    cluster       event         exit          history       job
    lun           man           metrocluster  network       qos
    redo          rows          san           security      set
    snaplock      snapmirror    statistics    statistics-v1 storage
    system        top           up            volume        vserver

ちなみに、qtreeコマンドを実行することで、クォータ制限が可能なフォルダが作成されるというような動きっぽい。
既存のフォルダに対してqtreeを実行してクォータ制限をかけるみたいなことは出来なさそう。
例えば、aaaというフォルダを手動で作成した後、それに後からクォータを掛けてみる。

FsxId06cf2b480cb59b9f6::> volume qtree create -vserver nozakiSVM -qtree-path /vol/vol1/aaa -security-style ntfs

Error: command failed: Failed to create qtree "aaa" in volume "vol1" Vserver
       "nozakiSVM". Reason: Qtree (or directory) "aaa" already exists.

このように既に存在すると怒られてしまってクォータを設定できない。

9.監査ログを閲覧する方法

ファイルアクセスの監査や、監査設定の作成参照

9.1. SVM での監査設定の作成
あらかじめ例えば「audit_log」というフォルダを作っておいてから、以下コマンドを実行。

 FsxId06cf2b480cb59b9f6::> vserver audit create -destination /vol1/audit_log -events file-ops,cifs-logon-logoff -format evtx

9.2. SVM での監査の有効化
監査設定の設定が完了したら、SVM で監査を有効にする。

FsxId06cf2b480cb59b9f6::> vserver audit enable -vserver nozakiSVM

9.3. ファイルおよびフォルダの監査ポリシーを設定する
ユーザーアクセスの試みを監査するファイルおよびフォルダーに監査ポリシーを設定する。NTFS 監査ポリシーは、Windows のセキュリティタブまたは ONTAP CLI を使用して設定できるが、前者は死ぬほどめんどくさそうだったので、2行で済む後者をここでは選択

FsxId06cf2b480cb59b9f6::> vserver security file-directory policy create  -vserver nozakiSVM -policy-name p1

FsxId06cf2b480cb59b9f6::> vserver security file-directory apply -vserver nozakiSVM -policy-name p1
[Job 89] Job is queued: Fsecurity Apply. Use the "job show -id 89" command to view the status of this operation.

AWSのドキュメントには、適用だけで作成のコマンドがなかったので注意

10.監査ログは「過去1年間保存、直近3ヶ月分は即調査可能な状態にする」という要件があり、1年後にログを削除するような設定は?

監査ログにはログローテート機能があります。これを月で例えば3月を指定すれば、毎年年度末にローテートされるようになるのではと

FsxId06cf2b480cb59b9f6::> vserver audit create -destination /vol1/audit_log -events file-ops,cifs-logon-logoff -format evtx -rotate-schedule-month
    January   February  March     April     May       June      July
    August    September October   November  December

さらに-rotate-limitで世代数も設定できるので、これを1にすれば1世代バックアップで過去1年分だけ保存されるようになるのでは

[-rotate-limit ]- ログ ファイルのローテーション制限
このパラメータは、監査ログ ファイルのローテーション制限を指定します。値 0 は、すべてのログ ファイルが保持されることを示します。デフォルト値は 0 です。たとえば、値 5 を入力すると、最後の 5 つの監査ログが保持されます。

さらに、-retention-durationで保存期間を制限できる。

[-retention-duration <[d][h][m][s]>]- ログの保存期間 }
このパラメータは、監査ログ ファイルの保存期間を指定します。値 0 は、すべてのログ ファイルが保持されることを示します。デフォルト値は 0 です。たとえば、値 5d0h0m を入力すると、5 日以上経過したログが削除されます。

なので1年だったら「-retention-duration 365d」を指定すればよい。

以上をまとめると、

FsxId06cf2b480cb59b9f6::> vserver audit create -destination /vol1/audit_log -events file-ops,cifs-logon-logoff -format evtx -rotate-schedule-month March -rotate-limit 1 -retention-duration 365d

まとめ

  • 動作が不安定(バグが多そう)
  • フォルダごとのクォータを設定しても可視化できない
  • qtreeやONTAPの情報がNetappのわかりにくい資料くらいしかない
  • クォータ設定をレポートに反映させるには、その都度ディスクへのクォータの有効化をオンオフする必要がある

所要時間

3時間

ユースケース

フォルダ単位でクォータを設定したい場合

FSx for Windows File Serverのストレージグループクォータを試してみた

サービス概要

FSx for Windows File Serverにおけるストレージクォータとは、ファイルシステム上でユーザーストレージクォータを設定して、ユーザーが消費できるデータストレージの量を制限できる機能です。

目的・やりたいこと

以下の質問を受け、疑問を解消したいため、検証で確認することになりました。


FSx for Windows File Serverのユーザ・グループのストレージクォータの仕様について、下記2点質問があります。

質問1
グループのクォータは、下記のどちら設定値でしょうか?(b.を想定)
a. グループ配下のユーザに対する一括設定としての設定値
b. グループとしてのストレージ消費を制限するための設定値

質問2
ストレージクォータの消費カウントは、ファイルの所有権に基づいてカウントされるとのことです。
質問1が”b. グループとしてのストレージ消費を制限するための設定値”の場合、グループに対するクォータ消費のカウントは下記のどちらになりますでしょうか?
a. グループが所有者となっているファイルの合計容量(グループ配下のユーザは無関係)
b. グループに所属するユーザが所有者となっているファイルの合計容量

【問題の背景】
提案中の案件でストレージクォータについて、「ユーザ・グループそれぞれで設定可能」とご説明したところ、クォータのカウントについて下記質問を頂きました。
■お客様からの質問
下記条件とした場合、①②の質問に対してはどのような回答となりますでしょうか?

  • グループ1に所属するユーザAがいるとする
  • グループ1に200GBストレージクォータをかけている
  • ユーザAに100GBストレージクォータをかけている

① ユーザAが個人フォルダに100MB、共有フォルダに200MB保存した場合、クォータの消費はどちらにどのようにカウントされるのか?
② ユーザAが保存できるファイルの容量はいくらになるのか?

【調べたこと】
ストレージクォータに関する公式ドキュメント
警告・制限の文言から、質問1は”b.グループとしてのストレージ消費を制限するための設定値”と解釈
下記文言から、ユーザのクォータの消費のカウントは所有権を元にしたカウントとなることはわかりました。
しかしながら、グループのカウントがわからず。。

ユーザーレベルでのストレージ消費は、ファイルの所有権に基づいて追跡されます。

【見解】
「■お客様からの質問」に対する回答想定は下記を考えております。
質問1が「b. グループとしてのストレージ消費を制限するための設定値」
質問2が「a. グループが所有者となっているファイルの合計容量(グループ配下のユーザは無関係)」
のとした場合の回答想定となります。

■回答想定
それぞれの回答は下記の想定となります。
クォータのカウントは"ファイルの所有者"でのカウントとなるため、ユーザAのグループ1への所属有無や保存先に関わらず、
所有者となっているファイル容量の合計でのカウントとなります。
① 全てのファイルがユーザAが所有者として保存された場合、ユーザAとして300MBのクォータ消費としてカウントされます。
② ユーザAが所有者として登録されているファイルの場合は100GBとなります。


対象となる技術

  • FSx for Windows File Server
  • ストレージクォータ

条件(導入にあたっての前提事項)

  • FSxやそのFSx接続用EC2は既に構築済みであることとします。

参考URL

留意点として、AD グループに対するストレージクォータ設定を行った場合、ファイルの所有者が「グループ」であるファイルを対象にクォータが適用されます。
グループに所属するユーザーが所有者のファイルについては、グループに対するストレージクォータ設定の対象とはならないため、それぞれのユーザーにクォータを設定することをご検討ください。

作業の流れ

事前作業

1.FSx接続用EC2は、FSxのマネージドADと同じドメインに参加している必要があるため、nozaki.comドメインに参加させておく。

2.ADユーザー(Admin@nozaki.com)でEC2に再度ログインし直す。

3.次のFSx接続コマンドを実行して、FSxへ接続する。

enter-pssession -ComputerName *Windows Remote PowerShell エンドポイント* -sessionOption $usSession -ConfigurationName FSxRemoteAdmin

ここで「Windows Remote PowerShell エンドポイント」は、FSx > ファイルシステム > [ネットワークとセキュリティ]タブで表示されるこれを指定すること!

ところが以下実行するとエラーが

PS C:\Windows\system32> enter-pssession -ComputerName amznfsx1aypwrib.nozaki.com -ConfigurationName FsxRemoteAdmin
enter-pssession : One or more errors occurred processing the module 'FSxRemoteAdmin' specified in the InitialSessionSta
te object used to create this runspace. See the ErrorRecords property for a complete list of errors. The first error wa
s: Cannot find the Windows PowerShell data file 'SmbLocalization.psd1' in directory 'C:\Windows\system32\WindowsPowerSh
ell\v1.0\Modules\smbshare\ja-JP\', or in any parent culture directories.
発生場所 行:1 文字:1
+ enter-pssession -ComputerName amznfsx1aypwrib.nozaki.com   -Configura ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OpenError: (:) [Enter-PSSession], RunspaceOpenModuleLoadException
    + FullyQualifiedErrorId : ErrorLoadingModulesOnRunspaceOpen

でもこれは色々なサイトで取り上げられている、日本語OSの場合にエラーになってしまうというもの。次のコマンドで言語を英語に変更すればよい。

PS C:\Windows\system32> $usSession = New-PSSessionOption -Culture en-US -UICulture en-us
PS C:\Windows\system32> enter-pssession -ComputerName amznfsx1aypwrib.nozaki.com   -ConfigurationName FsxRemoteAdmin  -sessionOption $usSession
[amznfsx1aypwrib.nozaki.com]: PS>

無事接続成功

4.接続したら、まずすべてのユーザ/グループに対するデフォルト設定のクォータを設定して、クォータを有効にするため、Enable-FSxUserQuotas コマンドを実行する。ここでは20MBの制限、10MBで警告されるようにしました。

PS> Enable-FSxUserQuotas -Enforce -DefaultLimit 20971520 -DefaultWarningLimit 10485760
PS> Get-FSxUserQuotaSettings

DefaultWarningLimit DefaultLimit State
------------------- ------------ -----
           10485760     20971520 Enforce

単位に注意。表示されるのはバイト単位のため、20MB=20M×1024K/M×1024B/K=20,971,520バイトになります。

5.ユーザーAdminがデフォルトで所属するDomain Adminsグループに200KBの制限(100KBの警告)を設定するため、Set-FSxUserQuotasコマンドを実行

PS> Set-FSxUserQuotas -Domain nozaki.com -Name "Domain Admins" -Limit 204800 -WarningLimit 102400

DiskSpaceUsed Limit  QuotaVolume                         User
------------- -----  -----------                         ----
0             204800 Win32_LogicalDisk (DeviceID = "D:") Win32_Account (Name = "domain admins", Domain = "NOZAKI.COM")

6.ユーザーAdminに2MBの制限(50KBの警告)を設定するため、Set-FSxUserQuotasコマンドを実行

PS>Set-FSxUserQuotas -Domain nozaki.com -Name Admin -Limit 2048000 -WarningLimit 512000

DiskSpaceUsed Limit   QuotaVolume                         User
------------- -----   -----------                         ----
4096          2048000 Win32_LogicalDisk (DeviceID = "D:") Win32_Account (Name = "admin", Domain = "NOZAKI.COM")

これで検証する準備は整いました。

検証手順

  • 最初に質問①の回答想定を検証するため、今のユーザーAdminでファイルを置いて、クォータの残りを確認する。

1.まず現状の空き領域を確認

Z:\>dir
 ドライブ Z のボリューム ラベルは DATA01 です
 ボリューム シリアル番号は E8ED-325D です

 Z:\ のディレクトリ

2023/11/15  09:47    <DIR>          .
2023/11/15  09:47    <DIR>          ..
2023/11/15  09:47    <DIR>          個人フォルダ
               0 個のファイル                   0 バイト
               3 個のディレクトリ       2,048,000 バイトの空き領域

2,048,000 バイト=2MBまでファイルを置けることがわかる。

2.ここで、1.8MB(=1,867,776 バイト)のファイルを個人フォルダに置いてみる。

Z:\>dir
 ドライブ Z のボリューム ラベルは DATA01 です
 ボリューム シリアル番号は E8ED-325D です

 Z:\ のディレクトリ

2023/11/15  09:47    <DIR>          .
2023/11/15  09:47    <DIR>          ..
2023/11/15  09:50    <DIR>          個人フォルダ
               0 個のファイル                   0 バイト
               3 個のディレクトリ         163,840 バイトの空き領域

2,048,000−1,867,776=180,224バイトなので、163,840バイトに対して約16KBの誤差があるのが気になるものの、空き領域がちゃんと減っているのがわかる。

3.今度は共有フォルダに100KB(=114,688 バイト)の画像ファイルを置いてみる。

Z:\>dir
 ドライブ Z のボリューム ラベルは DATA01 です
 ボリューム シリアル番号は E8ED-325D です

 Z:\ のディレクトリ

2023/11/15  09:57    <DIR>          .
2023/11/15  09:57    <DIR>          ..
2023/11/15  09:57           101,620 image.png
2023/11/15  09:50    <DIR>          個人フォルダ
               1 個のファイル             101,620 バイト
               3 個のディレクトリ          49,152 バイトの空き領域

163,840 バイトの空き領域−101,620 バイト=62,220バイトになり、またもや49,152 バイトの空き領域に対して13KBの誤差が気になるが、「サイズ」ではなく「ディスク上のサイズ」で計算すれば、
163,840 バイト−114,688 バイト=49,160バイトとなり、ほぼ誤差なく一致する。
これにより、質問①に対する回答想定が正しいことがわかる。

  • 今度はグループのクォータを検証するため、ファイルを置いてからファイル所有者を「Domain Adminグループ」に変更して、事前作業5.で実施したグループのクォータ200KBに引っ掛かるかどうかを確認する。

1.個人フォルダに置いてファイルを空にして元に戻し、共有フォルダに100KBのファイルを3つほど置いてみる。

この時の空き領域を確認

Z:\>dir
 ドライブ Z のボリューム ラベルは DATA01 です
 ボリューム シリアル番号は E8ED-325D です

 Z:\ のディレクトリ

2023/11/17  07:46    <DIR>          .
2023/11/17  07:46    <DIR>          ..
2023/11/17  07:26    <DIR>          Adminフォルダ
2023/11/17  07:30           101,620 image - コピー (2).png
2023/11/17  07:30           101,620 image - コピー.png
2023/11/17  07:30           101,620 image.png
2023/11/17  07:45    <DIR>          個人フォルダ
               3 個のファイル             304,860 バイト
               4 個のディレクトリ       1,687,552 バイトの空き領域

ユーザークォータ的にはバッチリまだ1.6MBほどファイルを置ける。でもグループ的にはどうか?

2.設置した画像ファイルの所有者を、このようにして順々にDomain Adminsグループに変更していく。

 

3.すると2つ目のファイルの所有者を変更しようとしたところで、このような空き領域不足エラーが


つまり、2つのファイルは合計すると200KB(正確には112 KB+112 KB=224KB)となり、Domain Adminsグループのクォータ200KBに抵触し、エラーが出たことになる。
これにより、質問②に対する回答想定も正しいことが証明されました!

にしても、普通に使っている分にはファイル所有者がグループになるってことはほぼ無い気がする。どんなケースを想定してるんだろうか。。

所要時間

1時間

まとめ

- グループのクォータは、グループとしてのストレージ消費を制限するための設定値
- グループに対するクォータ消費のカウントは、グループが所有者となっているファイルの合計容量(グループ配下のユーザは無関係)

例(ファイルサイズが100KBと想定)

ファイルA ファイルB ユーザーAクォータ グループBクォータ
所有者がユーザーA 所有者がユーザーA 200KB消費
所有者がユーザーA 所有者がグループB 100KB消費 100KB消費
所有者がグループB 所有者がグループB 200KB消費
 

WAFでIPごとではなくすべてのIPでレートベース制限を掛けられるか

目的・やりたいこと

WAFのレートベースルールとカスタムレスポンスで指定したページに一定のアクセス(コネクション)に達した際に、Sorryページなどには誘導できそうだが、ユーザ個別になるか全体で掛けられるかもう少し確認が必要
ということで、まずは情報がないか調査してみました。

AWSドキュメントAggregation options and keysでは、Count allを使えば全体で掛けられそうではある。

Count all – Count and rate limit all requests that match the rule's scope-down statement. This option requires a scope-down statement. This is typically used to rate limit a specific set of requests, such as all requests with a specific label or all requests from a specific geographic area.

訳すと、
「すべてカウント – ルールのスコープダウンステートメントに一致するすべてのリクエストをカウントし、レート制限します。 このオプションにはスコープダウンステートメントが必要です。 これは通常、特定のラベルを持つすべてのリクエストや特定の地理的領域からのすべてのリクエストなど、特定のリクエストのセットをレート制限するために使用されます。」
何のこっちゃわからない

Customize requests and responses with AWS WAFによると、「使用例 2: カスタム エラー ページ」より、以下の記載がある。

  1. AWS WAF には、5 分ごとに 100 件のリクエストを許可するレートベースのルールがあります。
  2. ユーザーが複数のリクエストを送信し、AWS WAF レートベースのルールのしきい値に違反しました。
  3. AWS WAF はユーザーからのそれ以上のリクエストをブロックします。
  4. AWS WAF カスタム レスポンス コード機能は、レスポンス コードをHTTP 307 – Temporary Redirectに変更し、 「リクエストが多すぎます」というメッセージを含むカスタム エラー ページで応答します。

この「ユーザー」というのが特定のユーザーなのか、ユーザー全体を指しているのかいまいち曖昧
ということで、やはり検証するのが早いということで検証することにしました!

対象となる技術

  • WAF
  • CloudFront

条件(導入にあたって前提事項)

  • 本検証はアクセス回数が重要であるため、キャッシュなどを含むことによる不正確なカウントになるなど余計な懸念を払拭するため、念のためCloudFrontでキャッシュしないようにしておく。 

参考URL

作業の流れ

概要図

インターネット---WAF---CloudFront---Web

事前作業

WAFでWeb ACLを作成します。
1.AWS WAF > Web ACLs で[Create web ACL]
2.AWSリソースはCloudFrontを選択

3.[Add rules] > [Add my own rules and rule groups]
4.[Rule builder]でTypeは[Rate-based rule]を選択
5.[Request aggregation]は最初は[Source IP address]を選択

6.Actionはこんな感じに

7.カスタムレスポンスボディはSorryページ風に

8.Web ACL作成
これで準備完了

検証手順

1.最初の5分間は以下のコマンドを実行して同じIPで100回アクセス

for i in {1..100}; do curl -s -o /dev/null -w "%{http_code}\n" https://d1z2cjnyfhe194.cloudfront.net/; done

2.120回目でレスポンスコード「307」が返ってくることを確認

200
200
200
200
200
200
200
200
200
200
307
307
307
307
307
307
307
307
307
307

なぜ100回ではなく120回目なのか腑に落ちないが、誤差も含めて約100回としておく

3.念のためブラウザでもSorryページを確認

4.次の5分間は、IPを変えて100回ずつアクセス

  • IP:106.154.144.14で試行
 % for i in {1..100}; do curl -s -o /dev/null -w "%{http_code}\n" https://d1z2cjnyfhe194.cloudfront.net/; done
 200
 〜略〜
 200
  • VPNに繋いで別のIP:134.238.x.xで試行
% for i in {1..100}; do curl -s -o /dev/null -w "%{http_code}\n" https://d1z2cjnyfhe194.cloudfront.net/; done
 200
 〜略〜
 200

5.この結果、トータルではなくIPごとにレート制限をカウントしていることがわかった

・ここでWeb ACLのルールを、[Source IP address]ではなく[Count all]に変更

6.次の5分間は、IPを変えて100回ずつアクセス

  • IP:106.154.144.14で試行
% for i in {1..100}; do curl -s -o /dev/null -w "%{http_code}\n" https://d1z2cjnyfhe194.cloudfront.net/index.html; done
 200
 〜略〜
 200
  • VPNに繋いで別のIP:134.238.x.xで試行
% for i in {1..100}; do curl -s -o /dev/null -w "%{http_code}\n" https://d1z2cjnyfhe194.cloudfront.net/; done
 200
 〜略〜
 200
307
307
307
307
307
307
307
307
307
307
307
307
307
307
307
307
307
307
307
307
307
307
307
307
307
307
307

IP:106.154.144.14は100回アクセス成功、一方の134.238.x.xは74回目で307に。つまりトータルで173回アクセスできたことになる。

所要時間

1時間

まとめ

IP [Source IP address] [Count all]
106.154.144.14 100 100
134.238.x.x 100 73

・[Source IP address]で制限した場合
⇨1つのIPで100回ずつアクセスできました。合計200回アクセス成功
・[Count all]で制限した場合
⇨1つ目のIPで100回アクセスできたものの、2つ目のIPは73回でSorryページにつながりました。

以上、想定より若干誤差はあるものの、[Count all]を使えばIPごとではなく、トータルでの制限が可能ということがわかりました!

VPCトラフィックミラーリングを使用してAWS上にネットワークIDSを作ってみた

サービス概要

VPCトラフィックミラーリングとは、ミラー対象に指定したソースENIを通るトラフィックの中身をミラーリングしたパケットを、別のターゲットENIやNLB、GWLBに転送することができる機能です。


https://d1.awsstatic.com/webinars/jp/pdf/services/20201021_AWS-BlackBelt-VPC.pdfより)

目的・やりたいこと

インターネットから来た通信をALBで受けてECS/Fargateに流す通信があり、その通信をミラーリングして外部のIDSに流したいという要件がある。AWSで実装できる構成があるか検証する。

対象となる技術

条件(導入にあたって前提事項)

  • 次のリソースをトラフィック ミラー ターゲットとして使用できます。
    • インタフェースタイプのENI
    • NLB
    • GWLBエンドポイント
  • ALB配下のEC2(Web)はあらかじめ作成してあるものとします。
  • ALBの作成やそのターゲットの作成の説明は割愛します。

参考URL

注意事項

  • トラフィック ミラーリングは、次の仮想 Nitro インスタンス タイプでは使用できません。
    • 汎用: M6a、M6i、M6in、M7g、M7i、M7i-flex
    • 最適化されたコンピューティング: C6a、C6gn、C6i、C6id、C6in、C7g、Hpc6a
    • メモリ最適化: R6a、R6i、R6id、R6idn、R6in、R7g、R7iz、X2idn、X2iedn、X2iezn
    • ストレージの最適化: I4g、I4i、Im4gn、Is4gen
    • 高速コンピューティング: Inf2、Trn1
  • トラフィック ミラーリングはベアメタル インスタンスでは利用できません。
  • Traffic Mirroring は、Nitro 以外のインスタンス タイプ C4、D2、G3、G3s、H1、I3、M4、P2、P3、R4、X1、および X1e でのみ使用できます。これには T2 インスタンスは含まれない
  • UDP 4789ポートでトラフィックをミラーするので、IDS側で受けられるかどうかの確認が必要

作業の流れ

概要図

事前作業

これが骨が折れました。なにせ20年くらい前のツールなので文献も古いし、参考になるサイトで最新のものがなかなかない。
機能も流石に無償だけあって有償の製品に比べたら全然劣ります。無料で最低限のIDSの検証だけできればいいというのならオススメ
AWSならNetwork FirewallのSuricataがあるし、あまり使われることはないでしょう。
ちなみにファイル改ざん検知に特化するならAIDE(Advanced Intrusion Detection Environment)がオススメ

1.Snortのインストール
EC2(Amazon Linux 2)に、Snortの最新版を入れます。

# wget https://www.snort.org/downloads/snort/snort-2.9.20-1.centos.x86_64.rpm
# amazon-linux-extras install epel -y
# yum install -y gcc flex bison zlib libpcap pcre libdnet tcpdump libnghttp2 daq daq-devel
# ln -s /usr/lib64/libdnet.so.1.0.1 /usr/lib64/libdnet.1
# yum install -y snort-2.9.20-1.centos.x86_64.rpm

2.Snortの起動確認

# systemctl start snortd
# systemctl status snortd
● snortd.service - SYSV: snort is a lightweight network intrusion detection tool that currently detects more than 1100 host and network vulnerabilities, portscans, backdoors, and more.
   Loaded: loaded (/etc/rc.d/init.d/snortd; bad; vendor preset: disabled)
   Active: active (running) since Fri 2023-10-27 15:41:52 UTC; 7h ago
     Docs: man:systemd-sysv-generator(8)
  Process: 12747 ExecStop=/etc/rc.d/init.d/snortd stop (code=exited, status=0/SUCCESS)
  Process: 12763 ExecStart=/etc/rc.d/init.d/snortd start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/snortd.service
           mq12781 /usr/sbin/snort -A fast -b -d -D -i eth0 -u snort -g snort -c /etc/snort/snor...

Oct 27 15:41:52 ip-10-0-43-242.ap-northeast-1.compute.internal snort[12781]:            Preproce...
Oct 27 15:41:52 ip-10-0-43-242.ap-northeast-1.compute.internal snort[12781]:            Preproce...
Oct 27 15:41:52 ip-10-0-43-242.ap-northeast-1.compute.internal snort[12781]:            Preproce...
Oct 27 15:41:52 ip-10-0-43-242.ap-northeast-1.compute.internal snort[12781]:            Preproce...
Oct 27 15:41:52 ip-10-0-43-242.ap-northeast-1.compute.internal snort[12781]:            Preproce...
Oct 27 15:41:52 ip-10-0-43-242.ap-northeast-1.compute.internal snort[12781]:            Preproce...
Oct 27 15:41:52 ip-10-0-43-242.ap-northeast-1.compute.internal snort[12781]:            Preproce...
Oct 27 15:41:52 ip-10-0-43-242.ap-northeast-1.compute.internal snort[12781]:            Preproce...
Oct 27 15:41:52 ip-10-0-43-242.ap-northeast-1.compute.internal snort[12781]:            Preproce...
Oct 27 15:41:52 ip-10-0-43-242.ap-northeast-1.compute.internal snort[12781]: Commencing packet p...
Hint: Some lines were ellipsized, use -l to show in full.

3.Snortの設定
ここではまず検知テストとして、pingを検知するルールを作ります。
/etc/snort/snort.conf に下記の設定を追加

include $RULE_PATH/icmp_test.rules

4.シグネチャ/etc/snort/rules/icmp_test.rules を作成

# vi /etc/snort/rules/icmp_test.rules
alert icmp any any -> any any (msg:"ICMP Packet"; sid:477;rev:3;)

5.local.rules、white_list.rules、black_list.rulesのファイルが無いと起動時にエラーになるので、起動前に作成しておく。

# touch /etc/snort/rules/local.rules
# touch /etc/snort/rules/white_list.rules
# touch /etc/snort/rules/black_list.rules

6.設定ファイルの文法チェック

# snort -T -c /etc/snort/snort.conf
〜略〜
Total snort Fixed Memory Cost - MaxRss:45512
Snort successfully validated the configuration!
Snort exiting

「successfully」が出てればOK
ここでエラーが出た場合は、ルールが無いとかがほとんどなので、設定ファイル内のルールを参照している箇所をひたすらコメントアウトしてください。例えばこんな感じ

#include $RULE_PATH/app-detect.rules
#include $RULE_PATH/attack-responses.rules
#include $RULE_PATH/backdoor.rules
#include $RULE_PATH/bad-traffic.rules
#include $RULE_PATH/blacklist.rules
#include $RULE_PATH/botnet-cnc.rules
#include $RULE_PATH/browser-chrome.rules
#include $RULE_PATH/browser-firefox.rules

7.設定を反映するため、Snort を再起動

# systemctl restart snortd

8.アラートファイルを作成

# touch /var/log/snort/alert

9.Pingを実行

# ping www.yahoo.co.jp

10.アラートが出ていることを確認

# cat /var/log/snort/alert
10/27-23:50:24.594682  [**] [1:477:3] ICMP Packet [**] [Priority: 0] {ICMP} 10.0.43.242 -> 183.79.219.252
10/27-23:50:24.601611  [**] [1:477:3] ICMP Packet [**] [Priority: 0] {ICMP} 183.79.219.252 -> 10.0.43.242
  • NLBの設定

今回はNLBをターゲットにミラーリングしているため、そのNLBの設定が大事になってきます。
自分はポート4789の設定を完全に忘れていてハマったため、注意してください。
NLBの設定はここが参考になりました。

1.UDP 4789ポートによるターゲットグループを作成しておきます。今回は遠隔地のオンプレミスIDSを想定しているため、ターゲットタイプは[IPアドレス]にしておきます。

2.リスナーをUDP 4789にしてNLB作成します。

  • VPC Traffic Mirroringの設定

VPC Traffic Mirroringでは、「ミラーターゲット」「ミラーフィルタ」「ミラーセッション」の3つを作成する必要があります。

1.トラフィックミラーターゲットの作成
ターゲットとして作成したNLBを選択します。

2.トラフィックミラーフィルタの作成
インバウンド/アウトバウンドともに念のため全許可のルールで作成しておきます。

3.トラフィックミラーセッションの作成
ミラーソースはキャプチャしたいALBのENIを選択、ミラーターゲットは先ほど作成したNLBを選択します。

セッション数は1、ミラーフィルタは先ほど作成したものを選択します。

検証手順

  • まず、ALBにアクセスして、そのパケットがSnortに流れているかを確認します。

1.ALBのURLにアクセス

2.Snort側でtcpdumpし、該当のHTTPSパケットが来ていることを確認

# tcpdump -i eth0 -n port 4789
IP 10.0.15.155.https > 134.238.*.*. 33800: Flags [P.], seq 5438:5779, ack 1067, win 179, options [nop,nop,TS val 402313766 ecr 2755605989], length 341
  • 次に、いよいよIDSで検知ルールを作成して検知します。

1.Snortで、UDP 4789宛のパケットを検知するルールlocal.rulesを作成

# vi /etc/snort/rules/local.rules
alert udp any any -> any 4789 (msg: "VXLAN Packet detected!"; sid:999;)

2.アラートファイルで検知を確認!

# tail /var/log/snort/alert
0/28-00:49:44.518171  [**] [1:999:0] VXLAN Packet detected! [**] [Priority: 0] {UDP} 10.0.15.155:65522 -> 10.0.43.242:4789
10/28-00:49:44.518172  [**] [1:999:0] VXLAN Packet detected! [**] [Priority: 0] {UDP} 10.0.15.155:65522 -> 10.0.43.242:4789

所要時間

2時間

IoT Coreのリソース登録をJSONの一括テンプレートで543台分登録できるか検証

サービス概要

AWS IoT Coreは、IoTデバイスAWSクラウドに接続するサービスです。

目的・やりたいこと

IoT Coreのリソース登録をJSONの一括テンプレートで543台分のデバイス登録ができるか試す。

対象者

IoT初心者〜中級者

対象となる技術

条件(導入にあたって前提事項)

・必要最低限のロールやポリシーがあらかじめ付与されているものとします。

参考URL

作業の流れ

事前作業

Cloud9開発環境を立ち上げ、ダミーのIoT仮想デバイスとして動作するプログラムのセットアップを行います。

  1. Cloud9の作成画面 (ここをクリック)を開く
  2. 以下のようにして環境作成

     

  3. 作成後、Cloud9 IDEを開きます。

     

  4. 以下のコマンドをターミナルで実行し、AWS IoT Device SDK Python v2 をインストール

pip3 install --user awsiotsdk

5.フォルダの作成と移動

mkdir -p ~/environment/dummy_client/certs/
cd ~/environment/dummy_client/

6.ダミーデバイスとなるソースコードをダウンロード

wget https://awsj-iot-handson.s3-ap-northeast-1.amazonaws.com/aws-iot-core-workshop/dummy_client/device_main.py -O device_main.py

7.AWS IoT Coreのコンソール画面 を開く
8.左のサイドメニューの下の方にある[設定]を選択
9.表示されたデバイスデータエンドポイントの[エンドポイント]の値をメモしておく

10.左のサイドメニューから セキュリティ > ポリシー をクリックし、画面中央の[ポリシーの作成]を押します。

11.以下のように設定して[作成]

12.左のサイドメニューより すべてのデバイス > モノ をクリックし、[モノを作成]
13.[多数のモノを作成]で[次へ]

14.ここで、以下のような行を543行分用意したパラメータファイルを作成しておく必要があります。

{ "ThingName" : "Hoge", "SerialNumber": "123", "Location":"Tokyo", "CertificateId":"2c0daf692c937080b3f90fd84e559e1a4f9c0ca653834c53ebad03346492170f"}
{ "ThingName" : "Fuga", "SerialNumber": "456", "Location":"Osaka", "CertificateId":"c71587c094819f9b8993e4da182736dcba2a3bdf9fe10b7b841a8174f8f74795"}
{ "ThingName" : "Boke", "SerialNumber": "789", "Location":"Nagoya", "CertificateId":"c71587c094819f9b8993e4da182736dcba2a3bdf9fe10b7b841a8174f8f74795"}

15.Excelでこのような行をドラッグして543行分作成しておきます。

16.これを「iot.json」として保存し、適当にS3にアップロードします。

検証手順

1.先ほどの「多くの AWS IoT モノを作成」画面に戻り、[登録タスクの詳細]で以下を設定します。
・S3 URL:16.でアップロードしたjsonファイルを指定
・IAMロール:モノの登録ができる権限と、S3が読める権限を与えたロール

2.[プロビジョニングテンプレート]には、一括登録のテンプレート例と、[AWS IoT] 複数のモノを一括で登録してみたに貼られているものを以下のように組み合わせて貼り付け、[登録を開始]

{
    "Parameters" : {
        "ThingName" : {
            "Type" : "String"
        },
        "SerialNumber" : {
            "Type" : "String"
        },
        "Location" : {
            "Type" : "String",
            "Default" : "WA"
        },
        "CertificateId" : {
            "Type" : "String"    
        }
    },
    "Resources" : {
        "thing" : {
            "Type" : "AWS::IoT::Thing",
            "Properties" : {
                "ThingName" : {"Ref" : "ThingName"},
                "AttributePayload" : { "version" : "v1", "serialNumber" :  {"Ref" : "SerialNumber"}}
            }
        },
        "certificate" : {
            "Type" : "AWS::IoT::Certificate",
            "Properties" : {
                "CertificateId": {"Ref" : "CertificateId"}
            }
        },
        "policy" : {
            "Type" : "AWS::IoT::Policy",
            "Properties" : {
                "PolicyDocument" : "{ \"Version\": \"2012-10-17\", \"Statement\": [{ \"Effect\": \"Allow\", \"Action\":[\"iot:Publish\"], \"Resource\": [\"arn:aws:iot:us-east-1:123456789012:topic/foo/bar\"] }] }"
            }
        }
    }   
}
  • ところがここでエラー


どうもAWS IoT ルールに必要なアクセスを付与するによると、信頼ポリシーに

"Service": "iot.amazonaws.com"

を追加する必要があるらしい。
なので自分は信頼ポリシーを次のように編集しました。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "lambda.amazonaws.com","iot.amazonaws.com"
                    ]
            },
            "Action": "sts:AssumeRole"
        }
    ]
}
  • 気を取り直して再チャレンジするも、またもや失敗

今度は登録を開始し始めてからのエラーなので、左メニューの[一括登録]のところにこのように失敗が出ます。


選択した状態で右上の[アクション] > 失敗ログ > ログ1の表示 で失敗ログがダウンロードされます。
今回は以下のようにエラーが記載されていました。

{"errorMessage":"com.amazonaws.services.iot.model.ResourceRegistrationFailureException: CertificateId 2c0daf692c937080b3f90fd84e559e1a4f9c0ca653834c53ebad03346492170f does not exist (Service: AWSIot; Status Code: 400; Error Code: ResourceRegistrationFailureException; Request ID: 8f0ad4c1-c6ae-4109-a8ba-901db89eb563; Proxy: null)","lineNumber":1,"offset":151,"response":null}

間抜けな話なんですが、適当に記載して登録した証明書ID「2c0daf692c937080b3f90fd84e559e1a4f9c0ca653834c53ebad03346492170f」が存在しないとのこと
ちゃんとここにある証明書IDを書かないといけません。

 

  • 三度目の正直で今度こそ登録成功

543台分あって2分かかりました。

所要時間

2時間