AWS Lambdaで自動化

AWSクラウドでコマンダーを実行

概説

コマンダーは、さまざまな問題を解決し、Keeper Security環境に関する貴重な情報が得られる強力なツールです。ローカルのデスクトップやサーバーで使用するだけでなく、AWSのようなクラウド環境でコマンダーを実行して、スケジュールされたまたはオンデマンドの要件を実行することも可能です。

この例では、コマンダーをAWS Lambdaと連携させ、ユーザーおよび使用状況のレポートを定期的に実行する方法を解説します。

要件

• ワンタイムのデバイスセットアップ用に、ローカルマシンにコマンダーをインストール

  • ダウンロードの詳細については、インストールとセットアップのページをご参照ください

• このLambda専用のKeeperユーザーアカウント (マスターパスワードによるログイン。SSOおよびMFAは、人の操作なしでは利用不可)

• Lambda関数、Lambdaレイヤー、SSM Parameter Storeパラメータの作成、およびAWS CloudShellの利用に必要な権限を持つAWS環境へのアクセス

ワンタイムのデバイスセットアップ

Lambdaで認証する前に、ローカルマシンで一度デバイス承認を完了する必要があります。Keeperでは、パスワード認証が成功する前にすべてのデバイスを承認する必要があります。Lambdaにはこの手順を完了する対話型シェルがないため、あらかじめ承認済みのデバイスIDを使用する必要があります。

手順

1. ローカルマシンで、Lambda専用アカウントを使ってコマンダーにログインします。

$ keeper shell

1. デバイス承認プロセスを完了します (エンタープライズの設定に応じて、メールリンク、プッシュ通知、2FA、管理者承認など)

2. ログインに成功したら、構成ファイル内の device_token を確認します。

$ cat ~/.keeper/config.json | grep device_token

コマンダーのインストール方法によって、構成ファイルの形式は異なる場合があります。CLIでは通常 device_token はトップレベルに保存されますが、SDKベースのインストールではネストされた構造 (devices[].device_token) を使用する場合があります。grep で結果が得られない場合は、ファイルを開いてトークンを手動で確認してください。

1. 以下の4つの値をLambda環境変数 (本番環境では後述のSSMパラメータ) として保存します。

   • KEEPER_DEVICE_TOKEN: 手順3で取得した、承認済みのデバイスID

   • KEEPER_USER: アカウントのメールアドレス

   • KEEPER_PASSWORD: マスターパスワード

   • KEEPER_SERVER: リージョンのエンドポイント (例: USは keepersecurity.com、EUは keepersecurity.eu)

保存が不要な項目

• private_key: パスワードログイン時にコマンダーが自動生成します。ウォームコンテナ最適化のために永続ログインを有効にする場合、private_key はそのセットアップの一環として /tmp に作成・保存されます。

• clone_code: パスワードログインのたびに自動再生成されます。永続ログインのセッション再開にのみ使用され、有効にした場合は /tmp で自動的に処理されます。

手順

AWS CloudShellを使用してLambdaレイヤーを作成

セットアップ

コマンダーは、AWS Lambdaで実行する環境と同じマシンでパッケージ化する必要があります。CloudShellでコマンダーパッケージを作成します。

このワークフローでは、AWS LambdaでPython 3.10または3.11を使用します (Python 3.9以前はAWS Lambdaでは利用できません)。Lambdaレイヤーを構築するCloudShell環境のPythonが、いずれかのバージョンになっているか、インストールされているPythonインタープリタで確認してください。

$ python3 --version
Python 3.11.6

CloudShellで利用できるPythonのバージョンが、AWS Lambdaで利用できるランタイムと一致しない場合は、先に進む前にPython 3.10または3.11をインストールしてください。

レイヤーコンテンツの構築

以下の段階では、CloudShell環境内で実行できる便利なシェルスクリプトを使用します。このスクリプトは、Lambdaレイヤーに必要な keepercommander パッケージを含むZIPファイルを作成します。

このスクリプトは、さまざまなコマンド呼び出しをまとめるだけでなく、keepercommander パッケージとその依存関係に特有のビルドプロセスの細かな問題を抽象化することで、レイヤーコンテンツのパッケージングを簡略化し、効率化することを目的としています。エラーが発生しにくいため、この方法を使用することを強くお勧めします。

スクリプトを見る

package_layer_content.sh

#!/usr/bin/env bash

#   AWS Lambda関数用の `keepercommander` 依存関係レイヤーを作成する
#   1. このスクリプトをCloudShell環境内の任意のフォルダにアップロードする
#   2. (オプション) プロジェクトの `requirements.txt` を同じフォルダにアップロードする
#   3. そのフォルダで以下を実行する
#             source ./package_layer_content.sh
#   4. `commander-layer.zip` が作成される。S3バケットにアップロードしてLambdaレイヤーの作成に使用する

MAX_LIB_SIZE=262144000
LAYER_FILENAME='commander-layer.zip'
LAYER_PATH=$(pwd)/$LAYER_FILENAME
LIB_DIR='python'
VENV='commander-venv'
OTHER_DEPS='requirements.txt'

# 過去のアーティファクトをクリーンアップ
test -f $LAYER_FILENAME && rm $LAYER_FILENAME
test -d $LIB_DIR && rm -rf $LIB_DIR
test -d $VENV && rm -rf $VENV

# ZIPファイル用のパッケージフォルダを作成
mkdir $LIB_DIR

# 仮想環境を作成して実行
python3 -m venv $VENV
source ./$VENV/bin/activate

# 依存関係をインストールしてパッケージ化
python3 -m pip install cryptography --platform manylinux2014_x86_64 --only-binary=:all: -t $LIB_DIR
python3 -m pip install keepercommander -t $LIB_DIR

if test -f $OTHER_DEPS; then
  python3 -m pip install -r $OTHER_DEPS -t $LIB_DIR
fi

deactivate

# 解凍後のライブラリサイズを確認
LIB_SIZE=$(du -sb $LIB_DIR | cut -f 1)
LIB_SIZE_MB=$(du -sm $LIB_DIR | cut -f 1)

if [ "$LIB_SIZE" -ge $MAX_LIB_SIZE ]; then
  echo "*****************************************************************************************************************"
  echo 'Operation was aborted'
  echo "The resulting layer has too many dependencies and its size ($LIB_SIZE_MB MB) exceeds the maximum allowed (~262 MB)."
  echo 'Try breaking up your dependencies into smaller groups and package them as separate layers.'
  echo "*****************************************************************************************************************"
else
  zip -r $LAYER_FILENAME $LIB_DIR
  echo "***************************************************************************"
  echo "***************************************************************************"
  echo 'Lambda layer file has been created'
  printf "To download, copy the following file path: %s\n%s\n$LAYER_PATH%s\n%s\n"
  echo 'and click on "Actions" in the upper-right corner of your CloudShell console'
  echo "***************************************************************************"
fi

# クリーンアップ
rm -rf $LIB_DIR
rm -rf $VENV

上記のスクリプトを使用するには、以下を実行します。

1. スクリプトをCloudShell環境内の任意のフォルダ（できれば空のフォルダ）にアップロードします。

   • (オプション) プロジェクトに依存関係のリストが含まれる requirements.txt がある場合、同じフォルダにアップロードすると、keepercommander パッケージに加えて依存関係もレイヤーに含められます。

2. 同じフォルダ内で、ターミナルで以下のコマンドを実行します。

source ./package_layer_content.sh

1. 現在のフォルダに commander-layer.zip が作成されます。このZIPファイルがLambdaレイヤーのコンテンツです。

Lambdaレイヤーのコンテンツにはサイズ制限があります (S3に保存する場合も同様です)。requirements.txt で追加の依存関係を含め、コンテンツの総サイズが制限を超えた場合、作成されたZIPファイルは使用できません。この状況を検出した場合、スクリプトはレイヤーコンテンツを出力せず、メッセージを表示します。

比較的簡単な解決策としては、依存関係を小さなグループに分割し、それぞれを個別のレイヤーにパッケージ化します。requirements.txtからいくつか (またはすべて) の依存関係を削除し、再度スクリプトを実行することができます。その結果、パッケージに含まれなかった依存関係は、標準のパッケージングプロセスを使用して別のレイヤーとしてパッケージ化できます。

コンテンツZipファイルからのレイヤーの作成と更新

結果として生成されるZIPファイルは50MB以上 (Lambdaレイヤーに直接アップロードできる最大サイズ) になるため、最初にAWS S3バケットにアップロードし、その後、生成されたS3アイテムをLambdaレイヤーにリンクする必要があります。

残りの手順を完了する方法はいくつかあります。GUIを利用する場合はAWSコンソールから操作できます。すでにCloudShell環境内にある場合は、組み込みのAWS CLIを使う方法が最も簡単なため、ここではCLIでの手順を記載しています。

1. まず、ZIPファイルをAWS S3にアップロードする必要があります。このタスク用にS3バケットをまだ作成していない場合は、CloudShellで以下のコマンドを実行して作成できます。

$ aws s3 mb <bucket-name>

ここで、 <bucket-name>はグローバルで固有の名前である必要があります。

1. 新しくパッケージしたZipファイルをCloudShellからS3バケットへアップロードします。

$ aws s3 cp ./commander-layer.zip 's3://<bucket-name>'

1. アップロードしたコンテンツでLambdaレイヤーを公開します。

$ aws lambda publish-layer-version --layer-name <layer-name> \
--description <layer-description> \
--content "S3Bucket=<bucket-name>,S3Key=commander-layer.zip" \
--compatible-runtimes python3.11

Lambdaの作成

AWS Lambdaで、Lambdaエディタを使用してPython関数を作成します。

lambda_handler 関数は、処理される際にLambdaによって呼び出されます。

以下は、コマンダーLambda関数の完全な例となります。

#  _  __
# | |/ /___ ___ _ __  ___ _ _ ®
# | ' </ -_) -_) '_ \/ -_) '_|
# |_|\_\___\___| .__/\___|_|
#              |_|
#
# Keeper Commander
# Copyright 2024 Keeper Security Inc.
# Contact: [email protected]

import os
import json

# Without mounted volumes, Lambda can only write to /tmp. 
os.environ['HOME'] = '/tmp'
os.environ['TMPDIR'] = '/tmp'
os.environ['TEMP'] = '/tmp'

from keepercommander import api
from keepercommander.__main__ import get_params_from_config

keeper_tmp = '/tmp/.keeper'
os.makedirs(keeper_tmp, exist_ok=True)

# ------------------------------------------------------
# Keeper initialization function
# ------------------------------------------------------
def get_params():
    # Read credentials from environment variables
    user = os.environ.get('KEEPER_USER')
    password = os.environ.get('KEEPER_PASSWORD')
    server = os.environ.get('KEEPER_SERVER', 'keepersecurity.com')
    device_token = os.environ.get('KEEPER_DEVICE_TOKEN')

    # Write config.json with the pre-approved device_token
    config_path = keeper_tmp + '/config.json'
    with open(config_path, 'w') as f:
        json.dump({
            'user': user,
            'server': server,
            'device_token': device_token
        }, f)

    # Load params from the config we just wrote
    params = get_params_from_config(config_path)
    params.password = password
    return params

# ------------------------------------------------------
# Keeper JSON report function
# ------------------------------------------------------
def get_keeper_report(params, kwargs):
    from keepercommander.commands.aram import AuditReportCommand
    from json import loads
    
    report_class = AuditReportCommand()
    report = report_class.execute(params, **kwargs)
    return loads(report)
    
# ------------------------------------------------------
# Keeper CLI function
# ------------------------------------------------------
def run_keeper_cli(params, command):
    from keepercommander import cli
    
    cli.do_command(params, command)
    
# ------------------------------------------------------
# Lambda handler
# ------------------------------------------------------
def lambda_handler(event, context):
    # Initialize Keeper Commander params with pre-approved device token
    params = get_params()

    # Keeper login (uses the pre-approved device_token) and sync
    api.login(params)
    api.sync_down(params)
    # Enterprise sync (for enterprise commands)
    api.query_enterprise(params)

    # Approve any OTHER pending devices in the enterprise
    run_keeper_cli(
        params, 
        'device-approve -a'
    )
    
    run_keeper_cli(
        params, 
        'action-report --target locked --apply-action delete --dry-run'
    )

    return get_keeper_report(
        params,
        {
            'report_type':'raw', 
            'format':'json',
            'limit':100,
            'event_type':['login']
        }
    )

このプログラムは以下の要素で構成されています。

lambda_handler 関数

この関数は、lambdaが実行されたときに呼び出されます。他のすべての関数は、この関数から呼び出す必要があります。

get_params() 関数

この関数は、環境変数から承認済みの device_token と認証情報を読み取り、device_token を含む config.json を書き込み、api.login() で使用できる params オブジェクトを返します。device_token は、ローカルマシンでのワンタイムセットアップ時に承認したデバイスIDです。

device_token が重要な理由

Keeperでは、パスワード認証の前にデバイス承認が必要です。Lambdaにはデバイス承認を完了する対話型シェルがないため、別のマシンであらかじめ承認した device_token が必要です。

複数のLambdaコンテナは同じ device_token を共有し、パスワードで同時に認証できます。各コンテナは同じ device_token をローカルの /tmp/.keeper/config.json に書き込み、独立してログインします。clone_code はパスワードログインのたびに再生成されますが、永続ログインを使用しないため影響はありません。

コマンダー関数

ログインして同期が完了すると、コマンダーSDKから関数を実行したりクラスを作成したりできます。上記のプログラムには2つの関数が含まれています。get_keeper_report() はJSON形式のレポートを取得します (audit-report コマンドと同等)。run_keeper_cli() はCLIコマンドを実行します (Python内でデータを返さずに実行のみ行います)。

Keeper認証情報の保存

上記の例では、Lambda環境変数から4つの値を読み取ります。

環境変数	説明
KEEPER_DEVICE_TOKEN	ワンタイムセットアップで取得した承認済みのデバイスID
KEEPER_USER	アカウントのメールアドレス
KEEPER_PASSWORD	マスターパスワード
KEEPER_SERVER	リージョンのエンドポイント (デフォルトは keepersecurity.com)

これは最も簡単な方法で、追加のAWSセットアップは不要です。ただし、環境変数は lambda:GetFunctionConfiguration 権限を持つユーザーに表示され、ログに出力された場合はCloudWatchログにも記録される可能性があります。本番環境のデプロイでは、代わりにSSM Parameter Storeを使用してください (以下のセクションをご参照ください)。

本番環境: SSM Parameter Storeの使用

本番環境のデプロイでは、認証情報をAWS SSM Parameter Storeの SecureString パラメータとして保存します。Lambdaの構成やCloudWatchログから認証情報を切り離し、保存時はKMSで暗号化し、IAMポリシーで読み取り権限の範囲を限定できます。

SSMに以下のパラメータを作成します (パスは例です。必要に応じてカスタマイズしてください)。

• /keeper/lambda/device_token

• /keeper/lambda/user

• /keeper/lambda/password

• /keeper/lambda/server

次に、Lambdaコード内の get_params() 関数を、以下のSSMベースの実装に置き換えます。

import os
import json
import boto3

# マウントされたボリュームがない場合、Lambdaは /tmp にのみ書き込み可能です。
os.environ['HOME'] = '/tmp'
os.environ['TMPDIR'] = '/tmp'
os.environ['TEMP'] = '/tmp'

from keepercommander import api
from keepercommander.__main__ import get_params_from_config

keeper_tmp = '/tmp/.keeper'
os.makedirs(keeper_tmp, exist_ok=True)

# モジュールレベルでSSMクライアントを一度だけ作成
ssm_client = boto3.client('ssm')

def get_ssm_parameter(name):
    response = ssm_client.get_parameter(Name=name, WithDecryption=True)
    return response['Parameter']['Value']

def get_params():
    user = get_ssm_parameter('/keeper/lambda/user')
    password = get_ssm_parameter('/keeper/lambda/password')
    server = get_ssm_parameter('/keeper/lambda/server')
    device_token = get_ssm_parameter('/keeper/lambda/device_token')

    # 承認済みの device_token を含む config.json を書き込む
    config_path = keeper_tmp + '/config.json'
    with open(config_path, 'w') as f:
        json.dump({'user': user, 'server': server, 'device_token': device_token}, f)

    # 書き込んだ構成から params を読み込む
    params = get_params_from_config(config_path)
    params.password = password
    return params

Lambda実行ロールには必要なIAM権限 (ssm:GetParameter をリソースARNでスコープ) のみを付与し、取得した認証情報をログに出力しないでください。

SSMの標準パラメータは無料です。SecureStringはKMSを使用し、KMSには独自の無料枠 (月20,000リクエスト) があります。一般的なLambdaワークロードでは実質的にコストはかかりません。組み込みのローテーション、きめ細かな監査、クロスアカウントアクセスが必要なエンタープライズデプロイでは、代わりにAWS Secrets Managerを使用してください (シークレットごとにコストが加算されます)。

永続ログインに関する注意

コマンダーは永続ログインに対応しており、以降のログインでパスワード入力を省略できます。ただし、マルチコンテナのLambdaデプロイでは永続ログインは利用できません。

Keeperのドキュメントでは、永続ログインは「動的なマルチサーバー環境向けではない」と記載されています。いずれかのインスタンスが同じ device_token でパスワードログインすると clone_code が再生成され、同じ device_token を共有する他のインスタンス上の永続ログインセッションは無効になります。永続化されたセッションはコンテナの /tmp にのみ存在し、AWSがコンテナを入れ替えると失われます。

単一コンテナのスケジュール実行Lambda (例: 同じウォームコンテナが毎回の呼び出しを処理する1日1回のcron) では、ウォーム起動時のレイテンシをわずかに短縮できる場合があります。セットアップ手順については、this-device コマンドのドキュメントをご参照ください。

ほとんどのLambdaの用途では、上記の例のように呼び出しのたびにパスワード認証を行う方法が適切です。

Lambdaの構成

タイムアウトの設定

Lambdaの設定にある一般構成セクションでは、タイムアウト値を変更することを推奨します。コマンダーの一部の関数は実行に時間がかかるため、スクリプトの処理時間がこの値を超えると、Lambdaは完了前に自動的に終了してしまいます。

タイムアウト値は任意の値に設定できますが、ほとんどの処理に対しては300秒 (5分) に設定しておけば十分です。

レイヤーの選択

Lambdaエディタで、上記で作成したレイヤーを選択して、Lambdaビルドにコマンダーパッケージを追加します。

実行スケジュールの作成

Lambdaを呼び出すEventCloudトリガーを作成し、適切な頻度 (たとえば、1日に1回や30日に1回) で動作するように設定します。

AWSでは、メールやSMSによるトリガーなど、他のいくつかのソースからLambdaを呼び出すように設定することもできます。その他のオプションについては、Lambdaの呼び出しに関するAmazonのドキュメントをご参照ください。

Lambda 関数の呼び出しメソッドについて - AWS LambdaAWS Lambda

次の手順

コマンダーの他の機能、Lambdaの呼び出し方法、またSNSなどのAWSサービス (SMSメッセージを含むさまざまなプッシュ通知の手法に活用可能) を組み合わせて、Keeperの処理を自動化してみましょう。

コマンダーSDKコードの使用例については、コマンダーのGitHubリポジトリにあるサンプルスクリプトをご参照ください。

Commander/examples at master · Keeper-Security/CommanderGitHub

コマンダーのさまざまなメソッドの詳細については、コマンドリファレンスのページをご参照ください。

コマンドリファレンス