こんにちわ。ソリューションアーキテクトのyskです。
ソラコムのソリューションアーキテクトおよびプロフェッショナルサービスコンサルタントがSORACOMを活用する技術情報をお届けするAsk SAシリーズの第二弾です。
この記事では現場のデータをSORACOM Airを利用して閉域網内でAmazon S3(以下S3)にアップロードする方法についてご紹介します。
Amazon S3はAmazon Web Service(以下AWS)のオブジェクトストレージサービスで、IoTのワークロードにおいてもデータ収集ストレージや外部との連携ハブとして多く活用される便利なサービスです。
IoTでは現場とクラウド間のデータ通信を閉域網内に閉じたいと相談をいただくケースも多く、S3へのアクセスもエンドツーエンドの閉域網内で実現する方法が求められる場合があります。(※この文脈での閉域網とは通信の途中経路でネットワーク的に一度もインターネットに出ないかグローバルIPアドレスによる通信を行わない構成を意味します)
この要望をどのように実現するかをご紹介しつつ、IoTデバイスからのS3アクセスで課題になりがちなアクセス用クレデンシャルのセキュアな割り当て・管理の手法についてもご紹介します。
【重要】
各種サービスのご利用にはご料金が発生しますので、あらかじめサービス紹介ページのご利用料金をご確認ください。
システム構成図
利用するSORACOMサービス
利用するAWSサービス
設定手順
1. S3への閉域アクセス
では早速S3に閉域アクセスする仕組みを構築していきましょう。SORACOM AirからS3に閉域アクセスする仕組みはAmazon S3にもともと備わっているVPCエンドポイント機能を活用します。
VPCエンドポイントはVPCのCIDRからのアクセスしか許可されていないので、SORACOM Airからのアクセス元IPアドレスをGatePeerでNATするのがポイントです。SORACOM Airからの通信をGatePeerを経由してS3のVPCエンドポイントにアクセスする構成をSORACOM Junction Redirectionで実現します。
【重要】本ポスト公開時点ではでS3のVPCエンドポイントは同一リージョン内でのアクセスのみサポートされており、お客様のGatePeerとS3が同じリージョンに配備されている必要があります。その他の制約については下記Webサイトをご確認ください。
SORACOM Canal、SORACOM Gate、SORACOM Junction Redirectionを構築していきます。
下記リンクの手順を参照し、ステップ3の疎通確認まで済ませます。(SORACOM Junctionの構築手順の中にSORACOM Canal/Gateの設定手順も含まれます)
SORACOM Junction のリダイレクション機能を利用し、VPGを通過するパケットの経路を変更する
https://dev.soracom.io/jp/start/junction_redirection/
次にVPCにS3用のVPCエンドポイントを設定します。GatePeerを作成したVPCとルートテーブルを予め控えておき、以下の流れでVPCエンドポイントを作成します。
以上で設定は完了です。早速疎通確認してみましょう。本ポスト公開時点ではS3までの途中のホップが無応答になっていればVPCエンドポイントが正しく有効になっているようです。(目に見えて変わった感じが無いのでご参考程度にお考えください。)
VPCエンドポイント有り
sudo traceroute -n -I bucket.s3-ap-northeast-1.amazonaws.com
traceroute to bucket.s3-ap-northeast-1.amazonaws.com (52.219.68.63), 30 hops max, 60 byte packets
1 10.10.0.254 35.307 ms 37.191 ms 37.155 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 52.219.68.63 48.060 ms 48.021 ms 48.985 ms
以上の設定で現場からS3までエンドツーエンドで閉域網アクセスの構成を実現できました。続いてS3アクセス用のクレデンシャルをどのようにセキュア&シンプルに配備するかご紹介します。
2. SORACOM Kryptonでのアクセス権限割当
現場のデバイスに固定のAWSアクセスキー(クレデンシャル)を配備するのはデバイスの製造・設定の負担になり、漏洩時のセキュリティリスクが高まります。中でもリスクが高いのが鍵の漏洩に気づけないケースです。デバイスに埋め込まれた固定のアクセスキーが漏洩した場合にそのまま外部でも利用可能なケースも多いのではないでしょうか。デバイスに割り当てた鍵が間違いなくそのデバイスで利用されていることをいかにコントロールするか重要になってきます。
SORACOM Krypton(以下Krypton)ではデバイスのハードウェア(SIM)による認証でデバイスに対して有効期限のあるAWSクレデンシャルを割り当てられます。言い換えるとクレデンシャルの払い出しに物理的なデバイスが必要な仕組みを実現できます。SORACOM AirのSIMは物理的に複製が困難な仕組みなのでハードウェアレベルでのなりすましリスクが低く、もし発行したクレデンシャルが漏洩しても有効期限が設定されているため影響範囲は限定的なものになるメリットがあります。
早速下記の手順を参照してSORACOM KryptonとAmazon Cognitoを連携して一時的なクレデンシャルでS3にアクセス出来るように設定していきましょう。
KryptonでCognitoのクレデンシャルを取得し、S3からファイルをダウンロードする
https://dev.soracom.io/jp/start/krypton_cognito/
上記手順にしたがってKrypton経由で有効期限のあるAWSアクセス用クレデンシャルを取得できるようになったらS3にアップロードするコードで利用出来るようにします。
一例としてデバイス(Raspberry Pi)からAWS CLIで東京リージョン(ap-northeast-1)のS3(s3://bucket)にアクセスする場合には以下のように設定します。
AWS CLIとjqをインストールします
sudo apt install jq awscli
続いてAWS CLIの設定を追加します
cat > ~/.aws/credential-provider.sh < EOF
#!/bin/bash
curl -X POST -H 'content-type: application/json' -s -o - https://krypton.soracom.io:8036/v1/provisioning/aws/cognito/open_id_tokens | jq '{IdentityId:.identityId,Logins:{"cognito-identity.amazonaws.com":.token}}' > cognito.json && aws cognito-identity get-credentials-for-identity --cli-input-json file://cognito.json | jq '.Credentials|{Version:1,AccessKeyId:.AccessKeyId,SecretAccessKey:.SecretKey,SessionToken:.SessionToken,Expiration:.Expiration|todateiso8601}' && rm cognito.json
EOF
chmod +x ~/.aws/credential-provider.sh
cat > ~/.aws/config << EOF
[profile krypton]
credential_process = "${HOME}/.aws/credential-provider.sh"
EOF
設定が終わったら以下のように利用します。AWS CLIは自動的にS3バケットのリージョンを補完してくれますが予め指定しておくほうがベターです。
aws --profile krypton --region ap-northeast-1 s3 ls s3://bucket
PRE 2019/
PRE 2020/
PRE AWSLogs/
なお上記サンプル内の credential-provider.sh
の実行結果はキャッシュされませんので高いスループットが必要な場合は別途キャッシュ機構をもたせることを強く推奨します。
S3へのアップロードはデータ量が大きくなりがちなのでデータ通信料に不安を感じられる方もいらっしゃいますが、SORACOMでは大容量のデータアップロードに対応したSIM plan-DU のご用意もございますので是非併せてご検討いただければと思います。
以上で現場のデバイスが閉域網経由で、かつセキュアなクレデンシャル管理の仕組みでS3にデータをアップロードする仕組みを実現できました。
ぜひお試しください!
なお、S3やDynamoDB以外のサービスと連携する場合は設定方法が異なりますのでこちらのリンクを参照ください。
AWS PrivateLinkとSORACOM CanalでAWSのマネージドサービスに閉域アクセスする
https://blog.soracom.jp/blog/2019/09/05/isolated-access-to-aws/
ysk