SCSKクラウドソリューション の技術ブログ
全1141件
みなさんこんにちは、鎌田です。 Prisma Cloud を使ったサービス開発、運営を行っている中での気づきや、使いこなし方などを皆さんと共有することで、クラウドセキュリティの重要性の認知度や対策レベルをみんなで徐々に上げられればいい、そういうモチベーションのブログ記事です。 ただの情報発信ではなく、Prisma Cloud の使いこなし方や、失敗から学んだ教訓など、少し具体的な実務よりの内容も共有していければと思います。 少し前に、Prisma Cloud の主の機能の１つ、CWPPについて確認、検証を行いましたので、これからそのナレッジを発信していきたいと思います。 今回は初回ということで、CWPPのアーキテクチャについて解説したいと思います。 CWPPのアーキテクチャ Prisma Cloud のCWPP機能は、大きく以下のアーキテクチャで成り立っています。 Prisma Cloud Console : セキュリティとコンプライアンスの管理を一元化するためのユーザーインターフェース Intelligence Stream（IS） : 最新の脅威インテリジェンスを提供するための機能 Defender : 各クラウドワークロード（仮想マシン、コンテナ、Kubernetesなど）に対するエージェント Radar : セキュリティ脅威やリスクをリアルタイムで可視化する機能 WildFire : 悪意のあるファイルや未知の脅威を分析し、インテリジェンスを提供するサービス これらの構成要素の関連を図にすると以下のようになります。 Prisma Cloud コンソールは、ISから脅威情報、Defenderからスキャン結果や不正な処理情報を受け取り、突き合わせを行い、危険な状態を可視化、アラート通知するというのが大まかな仕組みです。 そしてこれらのアーキテクチャをもとに、脆弱性・コンプライアンスの管理や、ランタイムプロテクション、ネットワークセグメンテーションといった機能を提供しています。 機能の説明は次回行いますので、今回はアーキテクチャについてもう少し具体的に解説していきます。 Intelligence Stream Prisma Cloud Intelligence Stream (IS) は、既知の脆弱性データベース、公式ベンダーフィード、各プロバイダーから集めた脆弱性データや脅威インテリジェンスをほぼリアルタイムに提供します。Prisma Cloud コンソールは自動的にISに接続し、特別な設定なしでアップデートをダウンロードします。IS は1日に数回更新され、コンソールは常にアップデートをチェックしてくれるので安心です。 Defender Defenderは、クラウド環境におけるワークロードやリソースをリアルタイムで保護するエージェントです。コンテナ、ホスト、サーバーレス環境など、さまざまなクラウドリソースを防御するために設計されています。仕様や動作原理については別の記事で詳しく解説予定ですので、ここでは、クラウド環境のワークロードを防御するためのエージェントという感じで理解しておいてもらえれば大丈夫です。 Radar 一言でいうと、クラウド環境におけるリソースの配置、接続状況、セキュリティリスクを視覚的に表示するダッシュボードのような機能を、よりグラフィカルな形で提供してくれるものです。以下のような情報をまとめてくれます。 クラウドリソースの全体マップ 各リソースのセキュリティステータス ネットワークトラフィックの視覚化 リソース間の依存関係と接続状況 WildFire Palo Alto Networksが提供するマルウェア分析および脅威インテリジェンスサービスで、以下のような解析を行います。 静的解析 ：ファイルのコードを解析し、悪意のあるパターンを検出します。 動的解析 ：サンドボックス環境でファイルを実行し、その動作を観察します。これにより、未知のマルウェアも検出できます。 機械学習 ：機械学習アルゴリズムを使用して、未知のマルウェアを検出し、既知のマルウェアと比較して分類します。 まとめ CWPPの構成要素について解説しました。初回ということでまずは簡単な解説までとなりますが、この後は各構成要素を深掘りしたり、導入や設定等、実際に手を動かしてみたところを、より具体的に解説していこうと考えています。 最後に、当社ではPrismaCloudを用いたマネージドサービスを提供しているので紹介させてもらいます。 ＝＝＝ 【CSPMマネージドサービス SmartOneCloudSecurity】 SmartOneCloudSecurityは、Prisma Cloud を用いたCSPMマネージドサービスです。Prisma Cloud の導入から設定変更まで、弊社技術担当者がお客様のCSPM対策をサポートします。CSPMの導入を検討中の方はもちろん、Prisma Cloud を利用中だけど機能や運用面でもっと上手に活用したい、というような課題をお持ちな方は、お気軽に下記URLからお問い合わせください。Prisma Cloud のPoCの相談も受けています。 New!! CWPPの導入サポートも始めました！ Smart One Cloud Security® パブリッククラウドのセキュリティ設定を診断/監視するマネージドCSPMサービスです。Palo Alto Networks社Prisma Cloud（CSPM機能）を使い易く、簡単に導入いただけます。 www.scsk.jp
こんにちは。SCSKのふくちーぬです。 2024/6/26時点で、Amazon InspectorのLambdaコードスキャンがPython3.12のランタイムでも動作確認できたので紹介します。 Amazon Inspector とは Amazon Inspector は、ソフトウェアの脆弱性やネットワークの接続性について AWS ワークロード(Amazon EC2,Amazon ECR,AWS Lambda)を継続的にスキャンする脆弱性管理サービスです。 Lambda スキャンについて 種類 説明 Lambda 標準スキャン Lambda 関数とそのレイヤー内のアプリケーションの依存関係をスキャンして、パッケージ脆弱性がないか調べます。 Lambda コードスキャン 関数やレイヤー内のカスタムアプリケーションコードをスキャンして、コードの脆弱性がないか調べます。 Amazon Inspector による AWS Lambda 関数のスキャン - Amazon Inspector Amazon Inspector による AWS Lambda 関数のサポートにより、Lambda 関数とレイヤーのセキュリティ脆弱性を継続的に自動評価できます。Amazon Inspector では、2 種類の Lambda スキャンを提... docs.aws.amazon.com 検証 今回は、Lambdaコードスキャンに着目して脆弱性の検出及び修正を実施します。 Amazon Inspector の有効化 以下手順に従って、有効化しておいてください。 15日間の無料トライアル期間があります。料金は、スキャンした回数に応じて課金されますのでご留意ください。 Amazon Inspector の開始方法 - Amazon Inspector Amazon EC2、Amazon ECR、および Lambda リソースタイプ全体の脆弱性を検出するためのベストプラクティス設定で Amazon Inspector をセットアップします。 docs.aws.amazon.com AWS CloudFormation テンプレート 以下のテンプレートをデプロイしてください。 ここでは、脆弱性を持つコードとして機密情報をハードコーディングしています。 AWSTemplateFormatVersion: 2010-09-09 Description: For Lambda Code Scan Parameters: ResourceName: Type: String Resources: # ------------------------------------------------------------# # Lambda # ------------------------------------------------------------# Function: Type: AWS::Lambda::Function Properties: FunctionName: !Sub ${ResourceName}-lambda-function Role: !GetAtt LambdaRole.Arn Runtime: python3.12 Handler: index.lambda_handler # Environment: # Variables: # AWS_SECRET_ACCESS_KEY: '{{resolve:secretsmanager:aws_secret_access_key:SecretString:sample_key::}}' Code: ZipFile: !Sub | import boto3 import os import json def create_session_noncompliant(): import boto3 # Noncompliant: uses hardcoded secret access key. sample_key = "AjWnyxxxxx45xxxxZxxxX7ZQxxxxYxxx1xYxxxxx" boto3.session.Session(aws_secret_access_key=sample_key) #def create_session_compliant(): # import boto3 # # Compliant: uses environment variable for secret access key. # sample_key = os.environ.get("AWS_SECRET_ACCESS_KEY") # boto3.session.Session(aws_secret_access_key=sample_key) def lambda_handler(event, context): create_session_noncompliant() # create_session_compliant() return { 'statusCode': 200, 'body': json.dumps('Hello form Lambda') } # ------------------------------------------------------------# # Log Group # ------------------------------------------------------------# FunctionLogGroup: Type: AWS::Logs::LogGroup Properties: LogGroupName: !Sub "/aws/lambda/${Function}" # ------------------------------------------------------------# # IAM Role # ------------------------------------------------------------# LambdaRole: Type: AWS::IAM::Role Properties: RoleName: !Sub ${ResourceName}-lambda-role AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: sts:AssumeRole Principal: Service: - lambda.amazonaws.com ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole 脆弱性の検出 パスワードやアクセス キーなどのアクセス資格情報を、ソース コードにハードコードしたため、脆弱性が検出されました。 ディテクターの名前を押下すると、以下のリンクに飛びます。 Hardcoded credentials | Amazon CodeGuru, Detector Library Credentials, such as passwords and access keys, should not be hardcoded in source code. docs.aws.amazon.com 脆弱性が発生した箇所もピンポイントで示してくれます。 内部で生成AIが利用され自動推論と機械学習を使用してコードを評価してくれるおかげで、修復方法も一目瞭然です。 ランタイムPython3.12でも検出されることを確認できました。 提案された修正コードを利用して、Lambdaを更新していきます。 AWS Secrets Manager の作成 機密情報をテンプレート内に記載するのではなく、AWS Secrets Manager から読み取るために事前にSecretを作成しておきます。 AWS Secrets Manager シークレットを作成する - AWS Secrets Manager AWS Secrets Managerでシークレットを作成する方法について説明します。 docs.aws.amazon.com 脆弱性を持つコードの修正 以下のテンプレートを使用して、スタックを更新します。 AWSTemplateFormatVersion: 2010-09-09 Description: For Lambda Code Scan Parameters: ResourceName: Type: String Resources: # ------------------------------------------------------------# # Lambda # ------------------------------------------------------------# Function: Type: AWS::Lambda::Function Properties: FunctionName: !Sub ${ResourceName}-lambda-function Role: !GetAtt LambdaRole.Arn Runtime: python3.12 Handler: index.lambda_handler Environment: Variables: SAMPLE_SECRET_ACCESS_KEY: '{{resolve:secretsmanager:aws_secret_access_key:SecretString:sample_key::}}' Code: ZipFile: !Sub | import boto3 import os import json # def create_session_noncompliant(): # import boto3 # # Noncompliant: uses hardcoded secret access key. # sample_key = "AjWnyxxxxx45xxxxZxxxX7ZQxxxxYxxx1xYxxxxx" # boto3.session.Session(aws_secret_access_key=sample_key) #def create_session_compliant(): import boto3 # Compliant: uses environment variable for secret access key. sample_key = os.environ.get("SAMPLE_SECRET_ACCESS_KEY") boto3.session.Session(aws_secret_access_key=sample_key) def lambda_handler(event, context): # create_session_noncompliant() create_session_compliant() return { 'statusCode': 200, 'body': json.dumps('Hello form Lambda') } # ------------------------------------------------------------# # Log Group # ------------------------------------------------------------# FunctionLogGroup: Type: AWS::Logs::LogGroup Properties: LogGroupName: !Sub "/aws/lambda/${Function}" # ------------------------------------------------------------# # IAM Role # ------------------------------------------------------------# LambdaRole: Type: AWS::IAM::Role Properties: RoleName: !Sub ${ResourceName}-lambda-role AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: sts:AssumeRole Principal: Service: - lambda.amazonaws.com ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole Amazon Inspector の確認 Amazon Inspector の検出結果画面にて、該当のLambdaが表示されていません。 無事コード脆弱性に対処することができました。 まとめ ・実環境でPython3.12についてもLambdaコードスキャンの対象として動作を確認しました。 日本語ドキュメントでは、Python3.12はサポートされていないと記述されておりますが、英語ドキュメントではサポートしている旨が記述されています。 Amazon Inspector でサポートされているオペレーティングシステムとプログラミング言語 - Amazon Inspector Amazon Inspector が脆弱性を検出するためにスキャンできるオペレーティングシステムとプログラミング言語について説明します。 docs.aws.amazon.com Operating systems and programming languages that Amazon Inspector supports - Amazon Inspector Learn about the operating systems and programming languages that Amazon Inspector supports to detect vulnerabilities. docs.aws.amazon.com ※2024/2/21時点では、日本語ドキュメント及び英語ドキュメント双方ともPython3.11までしかサポートしておりませんでした。実環境においてもPython3.12を検証したところ、スタータス欄に”サポートされていないランタイム”と表示され、コードスキャンの対象外であることを確認済みでした。 他のランタイムについては、本検証では未確認となりますので、Amazon Inspector 及び AWS Lambda 導入時にはご自身で検証の上ご利用ください。 最後に いかがだったでしょうか。 公式ドキュメントを英語で読むこと、きちんと動作検証をすることが重要であることを実感する良い機会になりました。 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥
こんにちは、SCSK株式会社の川原です。 6月20日～21日の2日間にわたり、幕張メッセで開催された” AWS Summit Japan 2024 “に出展しました。 SCSKはプラチナスポンサーとして、スポンサーセッションとブースを出展しました！ 出展概要に関する内容は、以下をご確認ください。 AWS Summit Japan 2024に出展します！ SCSKは 2024/6/20(木)～6/21(金)開催の日本最大の AWS を学ぶイベント「AWS Summit Japan」に出展します。 SCSKセッションでは、”データセンターのラックぜんぶ抜く！SCSK だからできる脱オンプレの秘策とは？”というテーマで、沖電気工業様のマイグレーション事例をご紹介いたします。 blog.usize-tech.com 2024.05.09 当社セッション クラウド Lift & Shift の秘訣 について、沖電気工業様と当社の取り組みをご紹介させていただきました。2日目の最終セッションにもかかわらず、多くの方々にご来場いただきました。 今回は、沖電気工業株式会社のCIOである高島様にご登壇いただき、共にお話しできたことで、クラウド移行を成功させるために両社がどのように協力し、その困難を乗り越えたのかをより深くご理解いただけたのではないかと思います。 足を運んでいただいた皆様ありがとうございました！ 出展ブース 展示ブースでは、「 AWS愛が、凄い。SCSK 」をテーマに、 SCSK独自ソリューションの4商材を展示、ミニシアターでは7つのAWS関連ソリューションから発表させていただきました 。出展ブースの詳細に関しては、以下の記事をご確認ください。 【近日開催！】AWS Summit Japan 2024「AWS愛が、凄い。SCSK」ブースのご紹介！ SCSKは、いよいよ開催が迫る「AWS Summit Japan」に出展します。 ブースでは「AWS愛が、凄い。SCSK」をテーマに独自ソリューションの4商材を展示、ミニシアターで7つのAWS関連ソリューションから発表いたします。 blog.usize-tech.com 2024.06.11 展示商材 展示商材のご紹介では、 実際のデモンストレーションを通じて、各ソリューションの具体的な機能や利便性を直接体験していただくことができました 。各ソリューションがどのようにお客様のビジネス課題を解決するのか、より深く理解していただけたことと思います。 ミニシアター ミニシアターでは、7つのAWS関連ソリューションについて1日に各2回ずつ講演を行いました。 最新の技術トレンドを交えながら、SCSKの豊富なソリューションの特長やAWS活用について専門スタッフがご紹介しました 。 当日表彰された AWS Ambassador や AWS Top Engineer も多く登壇し、多くのお客様が足を止めて聞いてくださいました。 予想を上回る多くのお客様にお立ち寄りいただき、盛況のうちに展示会を終了いたしました。ブース対応を担当したメンバーからは、嬉しい悲鳴を上げるほどの反響でした。ご来場いただいた皆様に心より御礼申し上げます！ フォローアップセミナーを開催します！ AWS Summit Japan 2024でのセッションや展示ブースを通じて、お悩みを解決したい方やご興味を持たれた方々に向けて、 クラウド移行 と 生成AI に関する フォローアップセミナーを開催いたします 。 本セミナーでは、Summitでの内容をさらに深掘りし、皆様のビジネスにどのように役立てるかについて詳しくお話しします。ぜひご参加ください！ クラウドネイティブ化にも対応！ ITX for MCP SCSK版でAWS移行を最適ルートで実現しよう SCSKのAI活用紹介セミナー ～AWSとInfoWeaveで社内チャットボットを始めよう～ このようなお悩みをおもちではありませんか？ 移行対象はDBや基幹系など様々だが、確実に移行するナレッジが不足 AWS移行後、運用やDX推進できるか不安 クラウドネイティブってなにから始めたらいいのかわからない・・・ AWSへの大規模移行やクラウドネイティブ化を最適ルートで実現するソリューションパッケージ「AWS ITトランスフォーメーションパッケージ(ITX) for MCP SCSK版」が、そのお悩み解決します。 本セミナーでは、AWS Summit Japan 2024でもご紹介したITXの事例や活用方法について、詳しくお伝えします。 お申し込みは こちら AIチャットを導入し業務効率を向上させたいと考えている中、スキルや体制の不足により、実現が難しい状況にお悩みではありませんでしょうか？ 本セミナーでは、AWSとRAG構築テンプレート「InfoWeave」を活用して社内チャットボットを簡単に始められる方法をご紹介いたします。 さらに、今年6月に開催されるAWS Summit Japan 2024のアップデート情報とあわせてAWSのAI系サービスについてもご紹介させていただきます。 社内情報を活用した生成AIを導入したい方には必見の内容となっていますので、是非ご参加ください。 お申し込みは こちら 最後に 弊社のセッションおよびブースへご来場いただいた方々、誠にありがとうございました！ 多くの皆様に会えたことをとてもうれしく思います。これからもお客様のビジネスを支援に尽力いたします。 今後ともSCSKのAWSサービスをよろしくお願いいたします。
CatoクラウドのBackhaulingという機能はご存知ですか？ 通常、Catoクラウド経由でインターネット接続をする際、トラフィックはCatoクラウドのPoPから出力されますが、Backhaulingを利用することで Catoクラウドに接続する特定サイト(拠点)から直接出力 させることができます。 今回は、Backhaulingについて解説していきます！ 「Internet Breakout」と 「Local gateway IP」 冒頭でお伝えした通り、BackhaulingをさせるとCatoクラウドのPoPではなく、Catoクラウドに接続する特定サイト(拠点)から直接インターネットに接続させることができます。 また、Backhaulingには以下の 2種類があります。 特定サイト(拠点)のSocketからトラフィックを出力させるか、 Firewallなどの特定の 機器から出力させるかにより異なります。 Backhaulingの種類とその違い Local gateway IP ： Firewallなどの既存機器 からトラフィックを出力させる場合に使用 Internet Breakout： Socket からトラフィックを出力させる 場合に使用 「Internet Breakout」は別記事でご紹介することにして、 本記事で は1つめの「Local gateway IP」についてご紹介 します！ 「 Local gateway IP」の ユースケース ※本記事では「Local gateway IP」のユースケースの一例をご紹介します。 まずは結論から。Backhaulingの「Local gateway IP」は Catoへの移行途中に活躍 します 。 現行ネットワークからCatoへ移行する際、Firewallなどのセキュリティアプライアンス機器からCatoクラウドのInternet Firewallへポリシーの移行が必要となりますが、Backhaulingを使えばこの移行作業を段階的に行うことができます。 例えば、下図のような構成の場合です。 本社内に設置された現行のFirewallを残しつつ、Firewallの上位にSocketを設置します。 この場合、支店のユーザやモバイルユーザからexample.comへのトラフィックのみを 本社 内のFirewallにて処理させることができます。 このように、Backhaulingの 「Local gateway IP」は主に 「一部トラフィックのみ、現行機器のセキュリティポリシーを適用させたい」といった場合に利用されます。 ここで注意いただきたいのは、 BackhaulさせたトラフィックもCatoクラウドを経由する という点です。 そのため、Catoクラウドのセキュリティポリシーも適用されます。 つまり、この例ですと 支店のユーザやモバイルユーザからexample.com へのトラフィックは、Catoクラウドのセキュリティチェックを突破したのちに本社のFirewallへルーティングされFirewallのセキュリティチェックが行われるという流れになります。 「Local gateway IP」の設定例 上記ユースケースを踏まえ、設定手順をまとめてみました。 構成例 今回は、下図の構成を想定します。 支店のユーザから、 example.com へのトラフィックのみをBackhaulさせ、本社のFirewallによるセキュリティチェックを適用させるというシナリオです。 設定手順 Backhaulingは下記の順番で設定をします。 Step１： Gatewayサイトの定義 →インターネット接続の出口となる拠点をGatewayサイトとして定義します。 → 今回は、Firewallが設置されている”本社”というサイトをGatewayサイトとして定義します。 Step２：Network Ruleの作成 →対象トラフィックをGatewayサイトに向けるためのルーティングの設定を行います。 → 今回は、支店のユーザから example.com へのトラフィックのみを”本社”にルーティングさせます。 Gatewayサイトの定義 設定箇所：Network＞Site＞Site Configuration＞Backhauling 「Use this site as a backhauling gateway」のチェックボックスにチェックを入れます。 「Select the destination for the traffic」の設定項目が出力されます。 ここで 「Internet breakout」か「Local gateway IP」のどちらかを選択しますが、今回は「Local gateway IP」を選択します。 上の手順で「Local gateway IP」を選択すると、IPアドレスの設定項目が出力されます。 ここではGatewayサイト内のどの機器で処理させるかを指定します。 今回はFirewallでトラフィックを処理させたいので「172.15.21.254」を入力します。 ここまででStep1のGatewayサイトの定義は完了です。 次にStep2のNetwork Ruleの作成に進みます。 Network Ruleの作成 中国のユーザからの接続の場合や、中国の拠点をGatewayサイトとする場合は、中国のインターネット規制に違反していないことを事前に確認し、設定を行う必要があります。 設定箇所：Network＞Network Rules 「New」からルールを作成していきます。 本記事ではNetwork Rulesの詳細な説明は省略いたしますが、今回は以下の通り設定をしています。 ・Name：Backhauling test ・Rule Type：Internet ・Source：Site(支店) ・App/Category：Domain(example.com) ・Configuration – Bandwidth priority：P255 – Priority Transport：CATO(Automatic) – Secondary Transport：None ConfigurationのRouting Methodでは「Backhaul via」を選択します。 「Backhauling Gateway Site」の設定項目が出力されるので、+ボタンからStep1で設定したGatewayサイトを選択します。 最後に「Save」ボタンで設定保存をします。 これで設定は完了です。 補足～「Local gateway IP」×「Backhaul hairpinning」～ 上の例では、Gatewayサイトの外からのアクセスとなっておりましたが、Gatewayサイト内からでもBackhaulさせることができます。 この場合は Backhaul hairpinning と呼ばれ、一部トラフィックはPoPを介してヘアピンされ、さらにGatewayサイトに転送されます。 例えば、下図のような構成の場合です。 本社のユーザからexample.comへのトラフィックのみ赤線の経路で本社内のFirewallに転送させ、Firewallにてトラフィックの処理をさせることができます。 このように、Backhaul hairpinningも上の例と同様で、一度 Catoクラウドを経由させることで移行作業を段階的に行うことが可能です。 Backhaul hairpinningの設定方法は通常のBackhaulingの設定とほとんど変わりません。 違うところは、Network RulesのRouting Methodです。 Backhaul hairpinningの場合は下図のように「Backhaul via」ではなく「Backhaul hairpinning」を選択します。 さいごに 本記事ではBackhaulingの「Local gateway IP」についてご紹介させていただきました！ 「Internet Breakout」については、別の記事にてご紹介します。
こんにちは。SCSKのふくちーぬです。 2024/6/20(木)～2024/6/21(金)に開催されたAWS Summit Japan 2024 に参加してきました。 AWS Summit Japan | 2024 年 6 月 20 日（木）, 21 日（金） オンデマンド配信中 AWS Summit は、AWSに関して学習し、ベストプラクティスの共有や情報交換ができる日本最大級の AWS イベントです。基調講演・150 を超えるセッション、さらに 250 以上の展示やハンズオンなどのEXPOコンテンツを体験し、皆様... aws.amazon.com 認定者ラウンジ 資格取得者のみ利用できるラウンジスペースと特典の配布会場です。 全冠の旨を伝えると、「おめでとうございます！」と言って貰えました。なんだか恥ずかしかったです（笑） SAP,DVA,SOAのステッカーとボトルは既に配布終了していました。。皆さんのAWS認定の注目の高さが分かります。 EXPO - AWS Summit Japan | AWS AWS Summit は、AWSに関して学習し、ベストプラクティスの共有や情報交換ができる日本最大級の AWS イベントです。 aws.amazon.com SCSKブース 弊社のブースにも立ち寄ってみました。 生成AIを活用したRAGソリューション（InfoWeave）、IoTを活用した製造業向けデジタル化ソリューション（Duetics）等、見どころたっぷりの展示やミニセッションでした。 生成AI RAGソリューション InfoWeave｜SCSK株式会社 生成AI RAGソリューション（InfoWeave（インフォウィーヴ））は、S-Cred⁺ ※ の生成AIオプションサービスです。 www.scsk.jp Duetics（デュエティクス） Duetics（デュエティクス）は、製造現場のデジタル化を支援するトータルソリューションです。製造業のお客様が求める高速かつ高い柔軟性を持つクラウドのデータ分析アプリケーションをはじめ、現場からクラウドへの直結ネットワーク、そして現場でのデ... www.scsk.jp 今年のAWS Summitは、AWS社含めたどのパートナー企業も生成AIやIoT,データ活用にかなり力をいれていました。 大規模クラウドインフラ設計・構築案件の歩き方 AWS社によるセッションです。 インフラ構築プロジェクトに参画している私としては、今回一番楽しみにしていたセッションとなります。 大規模クラウドインフラ設計・構築案件の歩き方 クラウド技術のコモディティ化により、エンタープライズ分野では近年、AWS 上での大規模なアプリケーション開発が一般的になりつつあります。これを支えるクラウドインフラ設計についても、求められる非機能要件の高度化と関連する AWS サービスの多... japansummit.awslivestream.com 聴講者として以下を想定しているそうですが、AWSに限らず全エンジニアにおすすめしたいコンテンツとなっています。 概要：大規模クラウドインフラの設計・構築案件で得た知見や学びが体系的にまとまっている 想定聴講者：インフラ設計発注者・受注者・内製担当者 設計 設計の骨組みづくり 以下は簡単なサンプルですが、インフラ設計書の目次となります。配属当時に知っていたら、どんなに助かったことかと思いました。 設計書一覧は可能な限り詳細に記載することで、バイネームで担当者を割り当て責任所在を明確にすること 設計事由を残すことで、設計の見直しができる状態にしておくこと 詳細設計書は、人へ分かりやすく伝えるために構築時点では詳細設計書+IaC。それ以降は、IaCを正とすること アプリ/インフラチームの責任分界 どこまでインフラチームまでの担当で、どこからアプリチームの担当であるか線引きすることはなかなか難しいですよね。 選定した開発方針とガバナンスを元に、要件に応じてインフラ/アプリチーム相互に議論して線引きを決めること コーディングルール プログラム言語で記述するのと同じくIaCでも、コーディングルールを決めておかないと品質低下につながります。 IaCにもコーディングルールは必要である（利用ツール、命名規則、スケルトンコードの利用等） 静的解析 IaCコードは、デプロイ前に必ず事前にチェックしておかないとデプロイ時に意図しないエラーやリソースが作成されるので留意しましょう。 書式のチェック(cfn-lint)、セキュリティの強制(cfn_nag)を実施するべき 構築 コスト管理はいますぐはじめる 開発開始時点で始めることが鉄則である（コスト異常検知や利用状況に気づけるように、最低限Budgets,Cost Explorerを導入しておくべき） クリティカルパスの特定 大規模/本番構築はIaCのみでは完結しないため、どのタスクがどの方法で構築することが合理的なのか、リードタイムはどれくらいなのか設計段階時に調査しておくべき 展開手順の整備 IaCコードのみに着目されがちですが、デプロイは繰返し実施されるため、更新手順や削除手順等のドキュメントを整備しておくことも忘れてはいけません。 IaC/手動/申請系を区別し、時系列や依存関係を踏まえて第三者でも分かりやすい表現でドキュメントを作成すること クラウドリソースのテスト 最後にテストについてです。 最低限、実環境・疎通性・性能の3要素に焦点を当ててテストを実施するべき Serverlesspresso – コーヒーをサーバレスとともに – カフェの注文システムをサーバレス構成で実装し、実際にコーヒーまで頂くことができるブースです。 Serverlesspresso バリスタの舞台裏 ~Happy Coffee, Happy Coding ! ~ - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS スマートフォンから注文できるコーヒー カウンター用のマルチテナント・イベント駆動型サーバーレス アプリケーション "Serverlesspresso" を提供する背景とその仕組みをご紹介します。 aws.amazon.com 5分間で10杯までしか注文を受け付けないことで、バリスタがきちんとお客さんを捌くことができます。 さすがにお客さんが増えてくると、QRコードの読み取りの待ち時間が増えているようでした。1人当たりのバリスタの処理時間をシステムの処理時間制約としている点が興味深かったです。 何とか注文できました。 無事エスプレッソを飲み、一息つくことができました。 『たまごっち』シリーズの進化と、AWS IoTで築いた 『Tamagotchi Uni』で つながる世界 続いてバンダイ様のセッションです。みなさんご存じ『たまごっち』の裏側の紹介です。 運用管理の負荷軽減と開発スピードを上げるために、サーバレスサービスをフル活用し設計しています。 IoTを利用する上で、重要な課題であるファームウェアのアップデート課題の向き合い方が非常に勉強になりました。 以下の2つを実践することで、解決していました。 アップデート対象機器に優先順位を付ける AWS IoT Device Managementの機能であるDynamic Groupの利用 この結果、世界中の皆さんの手元にあるどの『たまごっち』も仲間外れにされることなく、最新機能が配信されたと同時に遊ぶことが可能になっているんですね。 最後に いかがだったでしょうか。AWS Summit の現地レポートをお届けしました。 現地開催は、AWSの熱気や技術の面白さを生で感じ取ることができる良い機会だと改めて認識しました。 個人的には、7月発売予定の『たまごっち』が待ち遠しいです。 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥
こんにちは、ひるたんぬです。 先日AWS Summit Japanに初参加してきました。 最初から最後まで、その規模の大きさに圧倒され、あっという間に一日が経っていました。 参加レポについてはTechHarmonyにおいても他の方が書かれると思うので、今回はサミットに参加して、私がふと思った点について書こうと思います。 技術的な内容はありませんので、寝る前の読み物として…などで読んでいただけますと幸いです。 思ったこと AWS Summitの基調講演や各セッションを見ていると、多くのセッションでアーキテクチャの説明が行われていました。その際に、 〇〇はAPI Gatewayを通してアプリケーションからのアクセスを可能にしています。 ここの部分についてはサーバレスにて設計しています。 などの説明と同時にアーキテクチャ図が投影されていました。 これを見ながら説明を聞くと、「こういう構成をしているのか～」や、「ここってこうじゃないの、なんでだろう…」と、各セッションの取り組みをより深く理解することができるなぁ～と感じました。 （なんとなくでも、やっていることや構成が理解できるようになってきたのが嬉しい今日このごろです。） と同時に、それぞれのセッションで投影されるアーキテクチャ図のスタイルに少なからず違いがあり、「標準的な書き方やガイドラインって何かあるのかな？」と漠然と思ったので、調べてみました。 結論 ありました。それも結構細かったです。びっくりしました。 具体的には？ AWS アーキテクチャアイコンの配布サイト にてガイドラインを確認することができました。 以下にその内容についてまとめていきます。 ガイドラインはすべて英語で記載されています。 私がまとめた内容と実際のガイドラインに齟齬がある場合がありますので、厳密に確認が必要な場合などは、公式ガイドラインをご確認ください。 「Release 18-2024.02.06」の資料を基に作成しております。 アーキテクチャ図の作成手順 カラーテーマを選ぶ アーキテクチャアイコンには、背景色のタイプに合わせて「ライトテーマ」と「ダークテーマ」の2つが用意されています。作成物に合わせてより適切な方を選択します。 「ライトテーマ」はWebサイト、「ダークテーマ」はプレゼン資料で用いられる傾向があるようです。 リージョンやVPC（”Groups”と表現されています。）を配置する 大枠の構造として、グループを配置します。 アーキテクチャアイコンやリソースアイコンを配置する アイコンセットから必要なアイコンを選択し、適切な位置に配置します。 矢印でそれぞれのアイコンを結ぶ 矢印でアイコンを結び、ワークフローを表現します。 【オプション】ステップを追加する アーキテクチャ図内に番号を付与することで、手順をわかりやすく表現できるようにします。 縦長なレイアウト（Wordやブログ記事など）の場合 この場合はPowerPointのスライドを縦長に設定し、アーキテクチャ図を作成します。 PowerPointで「新しいプレゼンテーション」を作成する スライドのサイズを変更する 「デザイン」→「スライドのサイズ」より「ユーザー設定のスライドのサイズ」を押下します。 幅に「6.5″」、高さに「8.75″」と入力し、「OK」を押下します。 背景色は白色に設定しておきます。 ガイドラインに従いアーキテクチャ図を作成する 上記「アーキテクチャ図の作成手順」を参考にしてください。 図として貼り付ける 作成したアーキテクチャ図をすべて選択しコピーし、Wordにて「図として貼り付け」をします。 ブログ記事への貼り付け時や画像ファイルで保存したい場合などは、すべて選択したあとに右クリック→「図として保存」を選択することで可能です。 “Training and Certification” の場合 過去のガイドラインでは、スライド投影時のガイドラインとして記載されていたようですが、タイトルが変更されています。直訳すると「トレーニングと認定」ですが、これが何を指しているかはガイドラインから理解することはできませんでした… 過去のガイドライン記事の参考： 株式会社BeeX 「AWSのアーキテクチャ作図ガイドラインを確認してみた」 テキストサイズと色について テキストサイズは「16pt」で「黒色」にしてください。 アイコンサイズと色について アイコンサイズや色は変更しないでください。 線の太さと色について 線の太さは「2pt」で、色は変更しないでください。 アイコンや線の色を変更しない理由として、アクセシビリティの検証を行っているためとありました。 各種デザインの使用上の注意 以降では、種類別にアーキテクチャ図に挿入する上での注意事項が記載されています。 グループ（VPC, サブネットなど） サイズの変更方法 枠の右下を選択して実施してください。 ネスト(入れ子に)する場合 それぞれのグループの線の間に最低でも0.05″の間を空けてください。 引用：AWS 「 AWS アーキテクチャアイコン PowerPoint用ツールキット 」 プリセットに適したものがない場合は”genetic group”を使用すること 必要に応じて自分でカスタムグループを作成すること カスタムグループの雛形が用意されているため、アセットにあるアイコンと入れ替えて使用します。 入れ替えるアイコンはサイズ(ファイル名などに”32″とあります)や拡張子(.svg)の指定があります。 未承認のAWSアイコンを使用してグループを作成すること グループに設定するアイコンのサイズを変更すること アイコン サイズの変更 プレゼンテーションで使用する場合のみ拡大・縮小が許可されています。 縦横比を維持するため、Shiftキーを押下したままサイズの変更をしてください。 プレゼンテーション以外の用途では、サイズの変更はしないでください。 アイコンのトリミングをすること アイコンを反転・回転すること アイコンの形を変えること 矢印 プリセットを使用 矢印はプリセットよりコピーして使用してください。 サイズ（長さ）を変更する場合はShiftキーを押下したまま行ってください。 → 同一直線上でサイズ変更ができます。 可能な限り直線と折れ線（直角）で各アイコンをつなぐこと できない場合は、対角線（斜め）でつないでも良い プリセットの矢印の形状が利用できない・存在しない場合はデフォルトの形状で使用すること プリセットやデフォルト以外の形状の矢印を使用すること アイコンラベル フォントについて 書体は「Arial」で、フォントサイズは「12pt」にしてください。 ラベルの改行について サービス名は2行以内に収める必要があります。 また、”AWS”や”Amazon”と付く場合には、そのあとに続くサービス名を同じ行に含めなければなりません。そして、単語の途中で改行することは禁止されています。（下図参照） 引用：AWS 「 AWS アーキテクチャアイコン PowerPoint用ツールキット 」 ドキュメント内で正式名称に言及せずに、略称のみ記載すること 略称が重複すること 例）ELB：Elastic Beanstalk, Elastic Load Balancing 番号吹き出し スタイルについて 黒丸に白色の字で番号を記載します。（アーキテクチャ図内で目立つようにするため） アーキテクチャ図の複雑さに応じて2種類のフォーマットが用意されています。 できる限り直線的に番号を順に振ること 左から右、上から下、時計回りなどに振ってください。 吹き出しの位置はなるべく統一すること 同一アーキテクチャ図で、サイズの異なる吹き出しを使用すること 文字や記号など、数字以外をラベルとして使用すること 吹き出しのサイズを手動で変更すること 新しい形の吹き出しを作成すること おわりに 今回は技術的な内容とは少し離れましたが、AWSに触れる方の多くは一度は見ているであろうアーキテクチャ図について、そのお作法があるということを改めて知ることができました。今まで業務やこのブログにおいて何回かアーキテクチャ図を書いていましたが、ガイドラインに準拠していないところだらけで、少し恥ずかしく思っております。 ガイドラインに沿って作成することで、自然と見る相手にも分かりやすいアーキテクチャ図になると思うので、作図の練習を通してこのガイドラインを身につけていきたいなと思いました。 余談ですが… この度 AWS Japan APN ブログ や 弊社プレスリリース でも発表がありましたが、私(蛭田)は「2024 Japan AWS Jr. Champions」に選ばれました！ 入社から一年と少し、そしてAWSに触れ始めてからおよそ半年でここに選出いただけたことはとても光栄であり、今までの取り組みを認めていただけたのだと達成感を感じております。ですが、これに満足しておしまい…では決してありませんので、限られた任期(1年)の中を後悔することのないように日々邁進してまいります。
どうもこんにちは、SCSKの齋藤です。 みなさんは先日のAWS Summit Japanに参加しましたか？ 相変わらずの熱狂ぶりがすごかったですね〜 多くのセッションを通じて学びを得れたのと、社内外多くの知り合いに再会できて、大変刺激的な時間を過ごすことができました。 また、弊社の2024 Japan AWS Jr. Championsも輩出され、一緒に写真を撮ったりして、後輩のジュニチャンができたことを強く実感しました！後輩よ、頑張ってくれ〜 さて話は本題に入りますが、先日のAWS Summit Japanのセッションの中で気になることを学びましたので、早速検証して記事にしてみました。 概要 題名にもある通り、AWS StepFunctionsから直接APIを叩くことができるというものです。 以前からAWS StepFunctionsにはAPI Gatewayの連携はありまして、API Gatewayで作成されたAPIなら直接アクセスすることはできました。しかし、サードパーティAPIについては、Lambda関数を作成してアクセスする必要がありました。 ですが、なんとサードパーティAPIへのアクセスもStepFunctionsから直接叩けるようになってたとのことです。驚きですね！ このアップデート自体は、昨年のre:invent2023で発表されたものなのでまだ半年ちょっとしか経過していません。 ちょうど、私が4月から担当しているプロジェクトでも、サーバーレス開発をしているので、役立つかも知れないと思い検証してみました！ 検証内容 今回は下記のようなステートマシンとしております。 ステートマシンのワークフローの中で、APIGatewayに直接叩きに行く処理を先に2回実施し、そのレスポンスをもとに、サードパーティAPIを叩きに行くという流れとなります。 実際のプロジェクトなどで開発する場合では、リソース間の情報を連携してAPIを叩きにいくことは多いかと思いますので、こういった観点で検証してみました。 準備 今回の検証には主に下記3種類のリソースを作成します。 ① StepFunctionsステートマシン ② APIGatewayエンドポイント ③ サードパーティAPI（ApiGateway、Lambda） ①、②については、AWS側でテンプレートがあったので、それをそのまま使って構築しました。 ③については、サードパーティAPIをAPIGatewayで作成しました。（なんかややこしいですね。） APIGatewayのデプロイと、APIキーの作成、使用量の作成を行えば、実質サードパーティAPIができたも同然なので、そのAPIを叩きにいくようにしました。さらに、APIの裏側でLambdaを実装し、データの加工を少しだけ行うようにしました。 では、作成方法を解説します。 ①StepFunctionsステートマシン、②APIgatewayエンドポイント StepFunctionsのコンソール画面に行き、「ステートマシンの作成」を押下すると、テンプレート選択画面が出ます。 ここで、自分が実装したいことの類似テンプレートを選択すると、ある程度出来上がったステートマシンを見ることができます。 今回は、「API Gateway への呼び出しを行う」にチェックをつけ、次へ行きます。 テンプレートの活用方法が選択できるので、「デモの実行」を選択します。一旦ステートマシンを作成して、後ほどサードパーティAPIの処理を追加します。 今回のテンプレートは、 ① 最初のAPIGatewayでペットストアにペット商品の情報を登録（Post）し、 ② 2つ目のAPIGatewayで、ペットストアの情報を取得（Get）する 上記２つの流れのステートマシンとなっております。 次に画面が遷移するので、「デプロイと実行」をクリックし、ステートマシンの実行を行います。 CloudFormationの実行が走るので、少々待ちます。 デプロイが完了すると、実行画面が表示されます。 入力情報を作成し、「実行開始」をクリックします。デフォルトでサンプル値が用意されており、カメの商品情報を追加するデータとなっています。 実行が成功すると、画面上部に成功メッセージが表示され、ステートマシンの通過した処理を緑で表示します。 ちなみに、各アクションをクリックすると、イベント情報の詳細を確認できます。 下記２つののキャプチャは、1番最初に実行されるアクション「Add Pet to Store」の入力と出力です。 そしてさらに下記２つのキャプチャは、「Retrieve Pet Store Data」の入出力データです。入力データが、前の「Add Pet to Store」の出力データと同じになっていることを確認できますね。 出力データも長くて見切れていますが、「ResponseBody」で始まるフェーズと、「ExistingPets」で始まるフェーズがあるのを確認できます。 「ResponseBody」は新規に追加した情報で、「ExistingPets」は従来から存在しているデータのことを指していると思われます。 この後設定するサードパーティAPIは、「Retrieve Pet Store Data」の後に追加する予定のため、この出力データの一部である「ResponseBody」をサードパーティAPIのインプットにする予定です。 一旦、ここまででストップし、サードパーティAPIの作成に移ります。 ③ サードパーティAPI 先述した通りAPIGatewayとLambdaを使ってサードパーティAPIもどきを作成します。 Lambda 先にLambda関数を作成します。 サードパーティAPIの裏側で稼動するLambdaとして、今回は受け取ったリクエストをjson形式に変換し、ステータスコードとともに変換するという処理を実施します。 Lambdaのコンソール画面に移動し、「関数の作成」をクリックします。 任意の名前とランタイムで関数を作成します。今回はPythonを使います。 関数が作成されるのを確認します。 デフォルトで作成されたソースコードを少しだけ編集します。 ソースコードのjson.dumpの中身を入力値eventに置き換えます。入力値をjson形式に変換する処理を実施するためです。 下記のように変更いたら、「Deploy」ボタンを押下します。 デプロイの成功後、テストを実施するため、上記画面の「Test」を押下し、テンプレートを作成し、保存します。 その後、再び「Test」ボタンを押下して、テストを実施します。 json形式に変換してステータスコードとともに表示するので、下記のような結果になれば作成成功です！ APIGateway APIGatewayコンソールに移動し、「APIを作成」をクリックします。 APIの種類を選択する画面で、「REST API」を選択します。 「新しいAPI」を選び、APIエンドポイントタイプを「リージョン」にして、任意のAPI名で作成します。 そうすると、空のAPIが作成されました。 リソースの作成 空のAPIができたので、次はリソースを追加します。 先ほどの空のAPI作成画面の左上に「リソースを作成」というボタンがありますので、そこをクリックします。 リソースパス/の配下に、任意のリソース名を作成します。 作成されると、リソース欄に表示されるのを確認できます。 メソッドの作成 その後、同じ画面の「メソッドを作成」をクリックし、APIが叩かれた後の処理を定義します。 メソッドタイプをPOSTにし、統合タイプを「Lambda関数」に設定します。 Lambda関数は選択式なので、先ほど作成したものを選びます。 後の設定はデフォルトで良いため、画面下の「メソッドの作成」を押下します。 作成が完了すると、メソッド情報が表示されるようになります。 テスト API動作のテストを行います。 先ほどの画面の「テスト」というボタンを押下すると、テスト作成ができます。 リクエスト本文に{“test”:1}と入力し、テストの作成を行います。 テスト作成後にすぐにテストされるので、結果を確認します。 いいですね！ステータスコード200とjson化された入力値が返されており、先ほど作成したLambda関数と統合されているのがわかります。 APIキーの作成 APIリクエストにはAPIキーによる認証をした方が望ましいので、APIキーを作成します。 まず、作成したAPIの画面の左のバーから、「APIキー」を選択します。 その後の画面から、「APIキーを作成」を押下します。 任意の名前でAPIキーを作成します。 保存後に、APIキーが作成されていることを確認します。 なお、APIキーの四角の部分をクリックすると、APIキーがクリップボードにコピーされます。後ほど必要なので、手元に控えておいてください。 リクエストとAPIキーの結び付け リクエストにAPIキーを結び付けて、接続の際に認証するようにします。 まず、APIのトップ画面に遷移し、画面左の緑のPOSTをクリックします。そうすると、下記のような画面になるかと思います。 1番最初のリクエストのところでAPIキーが欲しいため、「メソッドリクエストの設定」の編集ボタンをクリックします。 「APIキーは必須です」をクリックし、保存を押下します。 デプロイ APIそのものは整ったので、公開する準備を行います。 再び、作成したAPIのトップ画面へ遷移します。 その画面の「APIをデプロイ」を選択します。 ステージを作成するため、下記情報を入力します。 今回は開発環境ということでdevというステージ名にしております。 入力後、デプロイを押下します。 使用量プランの設定 API公開前最後の設定を行います。 再び、作成したAPIの画面の左のバーから、「使用量プラン」を選択します。 その後の画面で「使用量プランを作成」をクリックします。 スロットリングやクォータの設定をできますが、今回はどちらもチェックを外して、「使用量プランを作成」をクリックします。 作成後、使用プランのページに遷移するので、ステージとAPIキーを追加していきます。 まずは、「関連づけられたステージ」→「ステージを追加」をクリックします。 APIの部分は作成したリソース名を選択し、ステージの部分は作成したステージを選択し、追加を押下します。 再び使用プランのページに戻り、今度は「関連づけられたAPIキー」にスイッチし、「APIキーを追加」を押下します。 既存のキーから、事前に作成したAPIキーを選択し、追加します。 これにてAPIを公開することができました。 StepFunctionsの編集 作成したサードパーティAPIをStepFunctionsに組み込みます。 事前に作成したStepFunctionsのページを開き、画面右上の編集ボタンを押下します。 編集画面の左側から「Call third-party API」を選択し、２つ目のAPIGatewayの後にドラッグ＆ドロップします。 挿入後、API接続の設定画面が表示されるので、設定を諸々入力します。 APIエンドポイント 作成したサードパーティAPIのURLを入力します。 メソッド 今回はPOSTするようにサードパーティAPIを作成したので、POSTを選択します。 Authentication APIキーの保存先の参照を設定します。これはEventBridgeConnectionというリソースを経由してSecretsManagerに保存されるため、そのリソースを作成します。「新しい接続を作成」をクリックしてください。 接続名は任意の名前を設定し、送信先タイプを「その他」で選択し、認証の部分で「APIキー」を選択します。 ヘッダー名には、 x-api-key と入力してください。 ヘッダー値には、APIキー作成時に控えておいた、APIキーを入力します。 作成後、再びStepFunctionsの画面に戻ります。 Authenticationの選択肢に、先ほど作成したものが追加されるので、選択します。 その後、リクエスト本文を入力します。 今回は、前のAPIGatewayの処理のレスポンスを受け取り、それをサードパーティAPIのリクエストにするため、「実行時に状態入力からリクエスト本文を取得」を選択し、「 $.ResponseBody 」と入力し、保存を押下します。 これは、先述した「①StepFunctionsステートマシン、②APIgatewayエンドポイント」の最後の方で、「Retrieve Pet Store Data」の出力の一部である「ResponseBody」をサードパーティAPIの入力にすると記載しましたのを反映してます。 先頭に$.をつけると、入力値のjson辞書から該当のKey値（今回でいうとResponseBody）の値を取得する設定を行うことができます。 もちろん、「ExistingPets」を入力としたい場合は、「$.ExistingPets」とすることで正しく渡されるのを確認できます。 保存が完了したら、画面右上から「終了」を押下します。 必要権限の設定 最後に、StepFunctionsに必要な権限を設定します。 ステートマシンの画面からIAMロールARNをクリックし、IAMの画面に遷移します。 最初に作ったStepFunctionsはAPIGatewayを直接叩くのみの権限しかないため、サードパーティAPIを叩くのに必要な権限をインラインポリシーで追加します。 下記のようなポリシーを作成してポリシーをアタッチします。 権限付与に参考にしたブログは下記のとおりです。 Third-party API integration in AWS Step-Functions The objective of this blog is to give a basic understanding of how Step Functions incorporate third-party API integratio... community.aws ステートマシンの実行 長かったですが、これでサードパーティAPIを叩く準備はできました。 今一度ステートマシンのページに移動し、画面右上の「実行を開始」をクリックします。 入力データを求められるので、最初のStepFunctions作成した時の入力データを参考に新しいペット情報を入力し、「実行を開始」ボタンを押します。 実行された後、ステートマシンのステータスを確認できるので、全て緑になっていれば成功です。 試しに、「Call third-party API」をクリックすると、画面右にデータが表示されます。 出力タブをクリックし、下にスクロールすると、ResponseBodyに1番最初に入力したデータが表示されております。 サードパーティAPIの裏のLambdaで処理された値なので、ResponseBodyの中にステータスコードとjson化された入力データが入っているのを確認できます。 これにより、前の処理で実行された APIGatewayの値をインプットに、サードパーティAPIにアクセスすることができると確認できました。 まとめ 今回はStepFunctionsからサードパーティAPIへの接続を試行してみました。 今回は検証初期段階ですが、私が現時点で気になることとして下記3点が挙げられます。 出力の整形はどこまで可能か？ 前後にLambdaを挟んでも情報を正しくやり取りすることは可能か？ APIエラー時の扱いもどこまで柔軟に設定が可能か？ 上記はこれから検証することとして今回のブログは一旦終わりにしたいと思います。 個人的な所感としては、APIのレスポンス情報を元に複雑なメッセージ整形処理を必要とする場合、Lambdaの方が適しているのかなと考えております。 APIを叩いて、その情報をほとんどそのまま次の処理に渡すなどの場合は、Lambdaではなく、この機能を活用した方が開発生産性が上がるかもしれません。
はじめに クラウドセキュリティは、多くの企業にとって必須の検討事項です。クラウドセキュリティを強化するため、CSPM（Cloud Security Posture Management）ツールの導入を検討すると、ツール選定が必要になります。ツール選定では多くの場合、自分のクラウド環境で提供されているCSPMツールを始めとして、サードパーティーのCSPMツールなどと比較・評価を行いますが、比較・評価にはそれなりの時間が必要となります。 そこで本記事では、AWS社のCSPMサービスであるSecurity HubとCPSMの代表的なサービスであるPalo Alto Networks社のPrisma Cloudを比較・評価して両ツールの違いを解説し、Prisma Cloudを利用することのメリットをお伝えいたします。 Prisma Cloudとは Prisma CloudというCSPMツールを初めて聞いた方向けに、まずはPrisma Cloudを説明いたします。 Prisma Cloud®は、クラウド ネイティブ アプリケーション保護プラットフォーム(CNAPP)であり、アプリケーション、データ、インフラストラクチャに対して業界で最も広範なセキュリティとコンプライアンスを提供し、コードからクラウド™まで、テクノロジー スタック全体のセキュリティ保護を支援します。 Prisma CloudのSaaSベースのソリューションは、ハイブリッドおよびマルチクラウド環境において、データ流出、インターネットに公開されているAPI、脆弱なCI/CDパイプラインが発生しやすい攻撃経路を検出するのに役立ちます。Prisma CloudのAIを活用したソリューションを活用して、問題をプロアクティブに予測し、ますます巧妙化する脅威や攻撃者に先手を打つことができます。 原文：Prisma Cloud® is a Cloud Native Application Protection Platform (CNAPP), providing you with the industry’s broadest security and compliance coverage for applications, data, and infrastructure, helping you secure your entire technology stack, from Code to Cloud™. Prisma Cloud’s SaaS based solution helps you detect attack paths prone to data exfiltration, internet exposed APIs, and vulnerable CI/CD pipelines across hybrid and multi-cloud environments. Leverage Prisma Cloud’s AI powered solution to proactively anticipate issues and stay ahead of increasingly sophisticated threats and attackers. 引用： Prisma Cloudへようこそ Prisma Cloudはアプリ、データ、インフラに対して、幅広くセキュリティを提供しているCSPMツールとなります。また、ハイブリッドやマルチクラウド環境において発生しやすい攻撃経路を検出できることや、AIを活用して問題を予測することができます。 Prisma Cloudでは以下3つの機能が提供されています。 クラウドセキュリティ ：認証や権限の問題、設定ミス、未解決の脆弱性に起因する攻撃からクラウド資産を保護するのに役立ちます。 アプリケーションセキュリティ ：アプリケーション依存関係の視覚化を提供し、IaC、ソースコード上のシークレットを検出するのに役立ちます。 ランタイムセキュリティ ：アプリケーションのライフサイクル全体にわたってマイクロサービス、ホスト、コンテナ、サーバーレス機能を保護するのに役立ちます。 クラウドへの移行の初期段階にある場合は、クラウドの体制をより詳細に可視化するために、クラウドセキュリティから始めることをPrisma Cloudは推奨しています。 本記事ではこのクラウドセキュリティで利用できる以下6つの機能をAWS Security Hubで利用できるかで比較・評価します。 監視可能なパブリッククラウド ポリシー コンプライアンス アラート リソース可視化 ダッシュボード 評価項目はPrisma Cloudの ドキュメント目次 をサマライズして作成しています。 また、本内容は2024年2月7日時点の情報となります。最新の情報を必ず各社メーカーのドキュメントでご確認ください。 監視可能なパブリッククラウド Prisma CloudとSecurity Hubで監視可能なパブリッククラウドです。 Prisma Cloudは複数のパブリッククラウドに対応していますが、Security HubはAWSのマネージドサービスのため、AWSしか監視できません。 項目 Prisma Cloud Security Hub 評価 評価 AWS 〇 〇 Azure 〇 × GCP 〇 × Oracle Cloud Infrastructure 〇 × Alibaba Cloud 〇 × 参考： クラウド・アカウント・オンボーディング (prismacloud.io) ポリシー Prisma Cloudではポリシーとは検知項目を表しており、Security HubにおけるFindingsと同じです。 組み込みポリシーの種類では、Prisma CloudはAWS用のポリシーだけで約1766種類が用意されています。 また、Prisma Cloudはマルチクラウド対応のため全パブリッククラウドのポリシーを合計すると約2940種類が用意されております。 検知領域では、Prisma Cloudのクラウドセキュリティは異常な振る舞い(ユーザ、ネットワーク、DNS)、特権アクティビティ、ネットワークの保護、ワークロードのインシデント、設定ミス・非推奨設定、脆弱性、攻撃経路の有無を検知できます。 また、Security Hubは組み込みのコンプライアンスによる検知や、他サービスとの統合(※1)により、侵入検出の結果(Amazon GuardDuty)、脆弱性(Amazon Inspector)、S3バケットポリシーの検出結果(Amazon Macie)、一般にアクセス可能なクロスアカウントリソース(IAM Access Analyzer)などを検知できます。 項目 Prisma Cloud Security Hub 評価 補足 評価 補足 組み込みポリシーの種類 〇 約1766種類 (※AWSポリシーのみ) 〇 約304種類 ポリシーのカスタマイズ 〇 SQLに似た独自言語でカスタマイズ △ Configでカスタムルール作成後に 統合で可能 (※2) ポリシー重要度 〇 5段階 〇 5段階 参考： Prisma Cloudポリシーの管理 ※1： AWS Security Hub での製品の統合 – AWS Security Hub (amazon.com) ※2： AWS Security Hub が AWS Config のマネージドルールとカスタムルールの評価結果を受け取るようになりました (amazon.com) コンプライアンス Prisma Cloudではコンプライアンス標準や業界標準に対してクラウド環境の健全性とコンプライアンス体制を表示、評価、レポート、監視、レビューできます。 本記事では、異なるバージョンのコンプライアンス標準は別の標準としてカウントしています。 項目 Prisma Cloud Security Hub 評価 補足 評価 補足 組み込みのコンプライアンス 〇 約67種類(AWSの場合※1) 〇 8種類(※2) コンプライアンスのカスタマイズ 〇 ポリシーを付け替えてカスタム可能 △ コンプライアンス内の ルール有効/無効のみ(※3) コンプライアンス準拠状況のレポート作成 〇 – × – 参考： Prisma Cloud Compliance ※1： Compliance Standards (prismacloud.io) ※2： Security Hub 標準のリファレンス – AWS Security Hub (amazon.com) ※3： すべての標準におけるコントロールの有効化と無効化 – AWS Security Hub (amazon.com) アラート Prisma Cloudではすべてのクラウド環境を継続的に監視し、ポリシー違反によってアラートを生成します。 Security Hubと同様にPrisma Cloudでもアラートを手動で無視できます。無視されたアラートは、同じポリシー違反が再び発生した場合でも無視された状態のままになります。( View and Respond to Prisma Cloud Alerts ) また、アラートのポリシーに関連付けられたCLIコマンドを実行し、違反を検出したクラウド環境でポリシー違反を自動的に修正できます。 項目 Prisma Cloud Security Hub 評価 補足 評価 補足 アラートのメール通知 〇 △ EventBridgeとSNSとの統合で可能 サードパーティへの通知 〇 Teams、Slackなど複数製品に対応 (※1) △ EventBridgeとLambdaとの統合で可能 アラートの無視 〇 〇 アラートの一時的な無視 〇 × リソースの自動修正 〇 △ EventBridgeとLambdaとの統合で可能 リソースを修正するための推奨手順 〇 ポリシーから手順を確認できる(※2) △ ドキュメントから個別に手順を確認する必要がある(※3) アラート状況のレポート作成 〇 × 参考： Prisma Cloud Alerts ※1： Prisma Cloudでの外部統合の構成 リソースを修正するための推奨手順の確認方法 Prisma Cloudの場合は、ポリシー毎に具体的な修正手順が記載されているため、アラートへ対応しやすいかと思います。 ※2： Risk Prioritization and Remediation (prismacloud.io) Security Hubの場合は、下記リンクのようにドキュメントが修正手順となります。修正手順の中でさらに別ドキュメントの参照を促され、ドキュメントを確認する手間が発生します。 ※3： Amazon Simple Storage Service コントロール – AWS Security Hub リソース可視化 Prisma CloudではAWSリソースだけでなく、マルチクラウドで所有しているリソースとアラート状況を一元的に確認できます。 また、それぞれのリソースで検知されているアラート数も容易に確認できます。 AWSではPrisma Cloudのようにリソースとアラート状況を一覧化する機能はなく、各サービス毎にリソースを確認する必要があります。 ※AWS Resource Explorerというサービスでリソースを横断的に検索、一覧化できますが、検索結果の上限が1000件などの制限があります。 参考： Prisma Cloud Asset Inventory(プリズマ クラウド アセット インベントリ) ダッシュボード Prisma Cloudではダッシュボードを利用して、クラウド環境の健全性とセキュリティ体制を可視化できます。 Prisma Cloudのダッシュボード 参考： Get Started with Dashboards Security Hubのダッシュボード CSPMの導入にかかる手間 Prisma Cloudではパブリッククラウドと接続することで全リージョンのリソース情報が取得されるため、リソースの可視化、監視を容易に開始できます(※1)。一方、Security HubではSecurity Hub自体がリージョンサービスのため、全リージョンを監視する場合、各リージョンでのSecurity Hub有効化と設定の管理が必要となります。また、他AWSサービス/サードパーティーと統合して利用する場合、各リージョン/サードパーティ毎に統合するサービスの有効化、設定の管理が必要となります。 ※AWS Organizationsにより、一部サービスで上記を自動化することも可能です。 ※1： 【CSPM】Prisma Cloud で AWS 環境をチェックしてみた 項目 Prisma Cloud Security Hub 評価 評価 CSPM導入にかかる手間 〇 △ まとめ 本記事では、AWSのSecurity HubとPrisma Cloudのクラウドセキュリティ機能を比較・評価して両ツールの違いを解説し、Prisma Cloudを利用することのメリットをお伝えしました。本記事でPrisma Cloudを利用することのメリットが伝わりましたら幸いです。 また当社ではPrisma Cloud利用して、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 ご興味のある方は是非、お気軽にお問い合わせください。
こんにちは、SCSK株式会社の小寺崇仁です。 このブログではZabbixのデータベース内部構成について紹介をしたいと思ってます。 第2弾としてアイテム、トリガーの設定を取得するSQLを作成してみます。 はじめに 私はZabbixの構築を主に担当しています。最近はZabbixと外部システムを連携しているお客様が増加傾向にあると感じています。外部システムと連携をしたいお客様にはサポート範囲内である、ZabbixAPIを使用した方法を案内しています。 しかし、Zabbixはオープンソースであり、RDBMSを使用しているため、DBを直接参照することが可能です。DBの知識がある方であれば、容易にデータ抽出ができますので、表の構造とサンプルSQLを記事にしたいと思います。 注意事項 Zabbixのデータベース内部に関するは情報が少ないです。そのため私が個人的にDBを解析して情報発信を行う非公式情報になります。 当社ではZabbixの有償サポートを実施しております。Zabbixのデータベース内部に関する問い合わせはサポート範囲に含まれておらず、本ブログの内容をサポート宛に問い合わせをいただいても回答ができません。 個人的に作成したSQLです。自己責任でご利用ください。間違っていた場合イベント等でこっそり教えてください。 テーブル定義(MySQL) items アイテム情報が格納されるのテーブルです。 Field 日本語名称 Type Null Key Default Extra itemid アイテムID bigint unsigned NO PRI NULL type タイプ int NO 0 0 – Zabbix エージェント 2 – Zabbix トラッパー 3 – シンプル チェック 5 – Zabbix インターナル 7 – Zabbix エージェント (アクティブ) 9 – Web アイテム 10 – 外部チェック 11 – データベース監視 12 – IPMI エージェント 13 – SSH エージェント 14 – Telnet エージェント 15 – 計算済み 16 – JMX エージェント 17 – SNMP トラップ 18 – 依存アイテム 19 – HTTP エージェント 20 – SNMP エージェント 21 – スクリプト snmp_oid SNMP OID varchar(512) NO hostid ホストID bigint unsigned NO MUL NULL name 名前 varchar(255) NO key_ アイテムキー varchar(2048) NO MUL delay 監視間隔 varchar(1024) NO 0 history ヒストリ保存期間 varchar(255) NO 90d trends トレンド保存期間 varchar(255) NO 365d status ステータス int NO MUL 0 0 – 有効なアイテム 1 – 無効なアイテム value_type 値のタイプ int NO 0 0 – 数値(浮動小数) 1 – 文字列 2 – ログ 3 -数値(整数) 4 – テキスト trapper_hosts トラッパーホスト varchar(255) NO units 単位 varchar(255) NO formula 計算式 varchar(255) NO logtimefmt ログ時間形式 varchar(64) NO templateid テンプレートID bigint unsigned YES MUL NULL valuemapid 値のマップID bigint unsigned YES MUL NULL params パラメータ text NO NULL ipmi_sensor IPMIセンサー varchar(128) NO authtype 認証タイプ int NO 0 username ユーザー名 varchar(64) NO password パスワード varchar(64) NO publickey 公開鍵 varchar(64) NO privatekey 秘密鍵 varchar(64) NO flags フラグ int NO 0 interfaceid インターフェースID bigint unsigned YES MUL NULL description 説明 text NO NULL inventory_link 在庫リンク int NO 0 lifetime 有効期間 varchar(255) NO 30d evaltype 評価タイプ int NO 0 jmx_endpoint JMXエンドポイント varchar(255) NO master_itemid マスターアイテムID bigint unsigned YES MUL NULL timeout タイムアウト varchar(255) NO 3s url URL varchar(2048) NO query_fields クエリフィールド varchar(2048) NO posts 投稿 text NO NULL status_codes ステータスコード varchar(255) NO 200 follow_redirects リダイレクト追跡 int NO 1 post_type 投稿タイプ int NO 0 http_proxy HTTPプロキシ varchar(255) NO headers ヘッダ text NO NULL retrieve_mode 取得モード int NO 0 request_method リクエストメソッド int NO 0 output_format 出力形式 int NO 0 ssl_cert_file SSL証明書ファイル varchar(255) NO ssl_key_file SSL鍵ファイル varchar(255) NO ssl_key_password SSL鍵パスワード varchar(64) NO verify_peer ピア検証 int NO 0 verify_host ホスト検証 int NO 0 allow_traps トラップ許可 int NO 0 discover ディスカバー int NO 0 uuid UUID varchar(32) NO ※参考：APIマニュアル https://www.zabbix.com/documentation/6.0/jp/manual/api/reference/item/object triggers トリガー情報が格納されるのテーブルです。 Field 日本語名称 Type Null Key Default Extra triggerid トリガーID bigint unsigned NO PRI NULL expression 式 varchar(2048) NO description 説明 text NO NULL url URL varchar(255) NO status ステータス int NO MUL 0 0 – 有効 1 – 無効 value 値 int NO MUL 0 priority 優先度 int NO 0 0 – 未分類 1 – 情報 2 – 警告 3 – 軽度の障害 4 – 重度の障害 5 – 致命的な障害 lastchange 最終変更 int NO 0 comments コメント text NO NULL error エラー varchar(2048) NO templateid テンプレートID bigint unsigned YES MUL NULL type タイプ int NO 0 state 状態 int NO 0 flags フラグ int NO 0 recovery_mode リカバリーモード int NO 0 recovery_expression リカバリー式 varchar(2048) NO correlation_mode 相関モード int NO 0 correlation_tag 相関タグ varchar(255) NO manual_close 手動クローズ int NO 0 opdata 操作データ varchar(255) NO discover ディスカバー int NO 0 event_name イベント名 varchar(2048) NO uuid UUID varchar(32) NO ※参考：APIマニュアル https://www.zabbix.com/documentation/6.0/jp/manual/api/reference/trigger/object functions アイテムとトリガーの関連付け情報が格納されるのテーブルです。 Field 日本語名称 Type Null Key Default Extra functionid 関数ID bigint unsigned NO PRI NULL itemid アイテムID bigint unsigned NO MUL NULL triggerid トリガーID bigint unsigned NO MUL NULL name 名前 varchar(12) NO parameter パラメータ varchar(255) NO 0 サンプルSQL アイテム取得 SELECT h.hostid AS ホストID ,i.itemid AS アイテムID ,h.name AS ホスト名 ,i.name AS アイテム明 ,i.key_ AS アイテムキー ,i.delay AS 監視間隔 ,i.history AS ヒストリ保存期間 ,i.trends AS トレンド保存期間 FROM hosts h LEFT JOIN items i ON h.hostid = i.hostid WHERE h.hostid = 10084 AND i.flags IN (0,4) トリガー取得 SELECT DISTINCT h.hostid AS ホストID ,h.name AS ホスト名 ,t.triggerid AS トリガーID ,t.description AS トリガー名 ,t.expression AS 条件式 ,CASE t.priority WHEN 0 THEN '未分類' WHEN 1 THEN '情報' WHEN 2 THEN '警告' WHEN 3 THEN '軽度' WHEN 4 THEN '重度' WHEN 5 THEN '致命的' END AS 重要度 FROM hosts h LEFT JOIN items i ON h.hostid = i.hostid LEFT JOIN functions f ON i.itemid = f.itemid LEFT JOIN triggers t ON f.triggerid = t.triggerid WHERE h.hostid = 10084 AND i.flags IN (0,4) ホスト＋アイテム＋トリガー取得 SELECT h.hostid AS ホストID ,i.itemid AS アイテムID ,t.triggerid AS トリガーID ,h.name AS ホスト名 ,i.name AS アイテム明 ,i.key_ AS アイテムキー ,i.delay AS 監視間隔 ,i.history AS ヒストリ保存期間 ,i.trends AS トレンド保存期間 ,t.description AS トリガー名 ,t.expression AS 条件式 ,CASE h.status WHEN 0 THEN '有効' WHEN 1 THEN '無効' END AS ホストステータス ,CASE i.status WHEN 0 THEN '有効' WHEN 1 THEN '無効' END AS アイテムステータス ,CASE t.status WHEN 0 THEN '有効' WHEN 1 THEN '無効' END AS トリガーステータス FROM hosts h LEFT JOIN items i ON h.hostid = i.hostid LEFT JOIN functions f ON i.itemid = f.itemid LEFT JOIN triggers t ON f.triggerid = t.triggerid WHERE h.hostid = 10084 AND h.status in (0,1) AND i.flags IN (0,4)
こんにちは、広野です。 AWS AppSync を使用したアプリケーションを開発する機会があり、リゾルバ、主に VTL の書き方に関してまとまった知識が得られたので紹介します。前回からの続きもので、今回は 1つの VTL で 2つのクエリをアトミックに (同期的に冪等性を担保して) 実行する方法を紹介します。 本記事では、VTL の書き方にフォーカスしています。ご了承ください。 AWS AppSync、リゾルバ、VTL の説明については以下の記事をご覧下さい。 AWS AppSync リゾルバ (VTL) の書き方サンプル No.1 - Amazon DynamoDB GetItem Amazon DynamoDB に VTL で GetItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.01.09 AWS AppSync リゾルバ (VTL) の書き方サンプル No.2 – Amazon DynamoDB BatchGetItem Amazon DynamoDB に VTL で BatchGetItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.01.19 AWS AppSync リゾルバ (VTL) の書き方サンプル No.3 – Amazon DynamoDB Query Amazon DynamoDB に VTL で Query をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.02.26 AWS AppSync リゾルバ (VTL) の書き方サンプル No.4 - Amazon DynamoDB PutItem Amazon DynamoDB に VTL で PutItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.02.26 AWS AppSync リゾルバ (VTL) の書き方サンプル No.5 – Amazon DynamoDB UpdateItem Amazon DynamoDB に VTL で UpdateItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.02.27 AWS AppSync リゾルバ (VTL) の書き方サンプル No.6 - Amazon DynamoDB 応用編 引数内のフラグにより処理を分ける Amazon DynamoDB に VTL でデータ読み書きをさせるときに、引数内のフラグにより実行させる処理を分岐する方法を紹介します。 blog.usize-tech.com 2024.06.17 AWS AppSync リゾルバ (VTL) の書き方サンプル No.7 - Amazon DynamoDB 応用編 2つのクエリを直列に実行 Amazon DynamoDB に VTL で 複数のクエリを直列に実行するときの書き方を紹介します。前のクエリの結果を後のクエリで使用することができるスグレモノです。 blog.usize-tech.com 2024.06.19 AWS AppSync を使って React アプリからキックした非同期ジョブの結果をプッシュ通知で受け取る 非同期ジョブを実行した後、結果をどう受け取るか？というのは開発者として作り込み甲斐のあるテーマです。今回は React アプリが非同期ジョブを実行した後に、AWS AppSync 経由でジョブ完了のプッシュ通知を受け取る仕組みを紹介します。 blog.usize-tech.com 2022.12.01 やりたいこと 以下のような処理をしたいです。冒頭、アトミックにという表現をしましたが、言葉を変えて説明します。 アプリからの1回のリクエストを受けて、リゾルバの中で 2つの書き込みオペレーションを実行したい。 ただし、2つのオペレーションが両方とも成功した場合にのみ、オペレーションをコミットしたい。もし片方が失敗した場合は、成功した方もオペレーションを無効にしたい。 これは、以下のように Amazon DynamoDB が提供している TransactWriteItems API を利用することで実現できます。 公式には、以下のドキュメントをご覧下さい。 Amazon DynamoDB Transactions: 仕組み - Amazon DynamoDB Amazon DynamoDB Transactions を使用すれば、複数のアクションをまとめてグループ化し、1 つのオールオアナッシングの TransactWriteItems または TransactGetItems オペレーションと... docs.aws.amazon.com 本記事のサンプルでは、アプリから AWS AppSync に「2つの書き込みオペレーション」リクエストを受けたとします。テーブル名はリゾルバの別の設定 (Data Source) で設定しますが、実際に使用されるのはリクエストマッピングテンプレート内で設定されたテーブルになります。 1つ目のオペレーション: パーティションキー pkey、ソートキー skey1、属性 attr1 をテーブル A に書き込み 2つ目のオペレーション: パーティションキー pkey、ソートキー skey2、属性 attr2 をテーブル B に書き込み Amazon DynamoDB に TransactWriteItems する VTL リクエストマッピングテンプレート { "version": "2018-05-29", "operation": "TransactWriteItems", "transactItems": [ ## 1つ目のオペレーションを定義 { "table": "TableA", "operation": "PutItem", "key": { "pkey": $util.dynamodb.toDynamoDBJson($context.arguments.pkey), "skey1": $util.dynamodb.toDynamoDBJson($context.arguments.skey1) }, "attributeValues": { "attr1": $util.dynamodb.toDynamoDBJson($context.arguments.attr1) } }, ## 2つ目のオペレーションを定義 { "table": "TableB", "operation": "PutItem", "key": { "pkey": $util.dynamodb.toDynamoDBJson($context.arguments.pkey), "skey2": $util.dynamodb.toDynamoDBJson($context.arguments.skey2) }, "attributeValues": { "attr2": $util.dynamodb.toDynamoDBJson($context.arguments.attr2) } } ] } transactItems の中に、配列で同期的に実行したいオペレーション、ここでは 2つの PutItem を定義しています。 関数 1 のレスポンスマッピングテンプレート この例では、エラーになったときは “error” を返すようにしています。 #if($ctx.error) $util.toJson({ "pkey": "error" }) #elseif($ctx.result) $util.toJson({ "pkey": $context.arguments.pkey }) #else $util.toJson({ "pkey": "error" }) #end まとめ いかがでしたでしょうか。 複数のオペレーション結果を総合的に判断させるクエリが作成が必要なケースはあると思います。もっとエラー時のレスポンスはきちんと作らないといけないとは思いますが。 本記事が皆様のお役に立てれば幸いです。
こんにちは、SCSK 池田です。 新しい試みとして、LifeKeeperの紹介動画を作成しました。 第一弾として、昨年11月に記事を掲載させていただいた「第１回 HAクラスタウェア「LifeKeeper」で可用性を高めよう！」の内容を動画化しました。 SCSKのYouTube公式チャンネル（以下リンク）からご視聴ください 5分で解説！HAクラスターソフトウェア「LifeKeeperとは？」 サムネイル 動作環境について 本動画コンテンツは、以下のツールを組合せて作成しています。 ◆パソコン Apple社 M3 MacBook Pro 16インチ ◆動画編集 Adobe社 Premiere Pro ※Adobe CreativeCloudサブスク ◆AIナレーション AHS社 VOICE PEAK AI音声合成技術を搭載した入力文字読み上げソフト 6人のナレーターと感情パラメータによる喜怒哀楽の表現も可能 ◆アニメーションソフト VYOND アニメーション映像製作プラットフォーム おわりに 今後、これまで記事にしてきた内容を動画でも公開していく予定ですので、ご期待ください！
こんにちは、広野です。 AWS AppSync を使用したアプリケーションを開発する機会があり、リゾルバ、主に VTL の書き方に関してまとまった知識が得られたので紹介します。前回からの続きもので、今回は 1つの VTL で 2つのクエリを直列に実行する方法 (パイプラインリゾルバ) を紹介します。 本記事では、VTL の書き方にフォーカスしています。ご了承ください。 AWS AppSync、リゾルバ、VTL の説明については以下の記事をご覧下さい。 AWS AppSync リゾルバ (VTL) の書き方サンプル No.1 - Amazon DynamoDB GetItem Amazon DynamoDB に VTL で GetItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.01.09 AWS AppSync リゾルバ (VTL) の書き方サンプル No.2 – Amazon DynamoDB BatchGetItem Amazon DynamoDB に VTL で BatchGetItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.01.19 AWS AppSync リゾルバ (VTL) の書き方サンプル No.3 – Amazon DynamoDB Query Amazon DynamoDB に VTL で Query をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.02.26 AWS AppSync リゾルバ (VTL) の書き方サンプル No.4 - Amazon DynamoDB PutItem Amazon DynamoDB に VTL で PutItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.02.26 AWS AppSync リゾルバ (VTL) の書き方サンプル No.5 – Amazon DynamoDB UpdateItem Amazon DynamoDB に VTL で UpdateItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.02.27 AWS AppSync リゾルバ (VTL) の書き方サンプル No.6 - Amazon DynamoDB 応用編 引数内のフラグにより処理を分ける Amazon DynamoDB に VTL でデータ読み書きをさせるときに、引数内のフラグにより実行させる処理を分岐する方法を紹介します。 blog.usize-tech.com 2024.06.17 AWS AppSync を使って React アプリからキックした非同期ジョブの結果をプッシュ通知で受け取る 非同期ジョブを実行した後、結果をどう受け取るか？というのは開発者として作り込み甲斐のあるテーマです。今回は React アプリが非同期ジョブを実行した後に、AWS AppSync 経由でジョブ完了のプッシュ通知を受け取る仕組みを紹介します。 blog.usize-tech.com 2022.12.01 やりたいこと 以下のような処理をしたいです。 アプリからの1回のリクエストを受けて、リゾルバの中で直列した 2 つの処理を実行した結果をアプリにレスポンスする。 アプリへのレスポンスは、1つ目の処理 (関数1) の結果を 2つ目の処理 (関数2) が受け取り、処理に使用する。 これは、以下のようなパイプラインリゾルバを構築することで実現できます。 公式には、以下のドキュメントをご覧下さい。 リゾルバーのマッピングテンプレートの概要 - AWS AppSync AWS AppSync 対応のリゾルバーのマッピングテンプレートの概要 docs.aws.amazon.com 本記事のサンプルでは、アプリから AWS AppSync に「グラフに使用する 3 つのデータを取得する」リクエストを受けたとします。Amazon DynamoDB には適切なデータがある想定です。テーブル名はリゾルバの別の設定 (Data Source) で行います。 1つ目の関数: パーティションキー pkey、ソートキー skey1 が “TRUE” である件数をテーブル A から取得 2つ目の関数: パーティションキー pkey、ソートキー skey1 が “FALSE” である件数をテーブル A から取得 3つ目の関数: パーティションキー pkey、ソートキー skey2 が “Red” から始まる件数をテーブル B から取得 pkey は pkey という変数名で引数としてアプリから値を渡される これらの件数を、以下のフォーマットの JSON データとしてまとめてレスポンスする。 { "true": xx, "false": xx, "red": xx } Amazon DynamoDB に命令する VTL まず、大元締めのパイプラインリゾルバのマッピングテンプレートをつくりますが、実体はほぼ空です。実処理は各関数のリゾルバに記述します。 パイプラインリゾルバのリクエストマッピングテンプレート 何もしません。(笑) {} パイプラインリゾルバのレスポンスマッピングテンプレート 最後に実行された関数から受け取ったレスポンスをそのままパイプラインリゾルバのレスポンスとしてアプリに返す仕様にします。 $util.toJson($context.result) 関数 1 のリクエストマッピングテンプレート { "version": "2018-05-29", "operation": "Query", "query": { "expression": "#pkey = :pkey AND #skey1 = :skey1", "expressionNames": { "#pkey": "pkey", "#skey1": "skey1" }, "expressionValues": { ":pkey": $util.dynamodb.toDynamoDBJson($context.arguments.pkey), ":skey1": $util.dynamodb.toDynamoDBJson("TRUE") } }, "nextToken": $util.toJson($util.defaultIfNullOrEmpty($context.arguments.after, null)), "scanIndexForward": false, "consistentRead": false, "projection": { "expression": "pkey" } } シンプルな、条件に合致する行の件数をカウントしたいだけのクエリなので、projection に pkey のみを指定しています。これによりレスポンスのデータ量を節約します。 関数 1 のレスポンスマッピングテンプレート 結果のうち、件数だけを取得したいので、以下のように scannedCount を使用します。 $util.toJson({ "true": $ctx.result.scannedCount }) このレスポンスは、関数 2 に渡されます。 関数 2 のリクエストマッピングテンプレート { "version": "2018-05-29", "operation": "Query", "query": { "expression": "#pkey = :pkey AND #skey1 = :skey1", "expressionNames": { "#pkey": "pkey", "#skey1": "skey1" }, "expressionValues": { ":pkey": $util.dynamodb.toDynamoDBJson($context.arguments.pkey), ":skey1": $util.dynamodb.toDynamoDBJson("FALSE") } }, "nextToken": $util.toJson($util.defaultIfNullOrEmpty($context.arguments.after, null)), "scanIndexForward": false, "consistentRead": false, "projection": { "expression": "pkey" } } 本サンプルでは、関数 2 は関数 1 のソートキーの条件を変えただけのもので、ほとんど同じです。skey1 が FALSE である件数を取得する目的です。 関数 2 のレスポンスマッピングテンプレート ここは関数 1 とは少し変わります。関数 1 のレスポンスを受け取ったものをここでマージします。 $util.qr($ctx.prev.result.put("false", $ctx.result.scannedCount)) $util.toJson($ctx.prev.result) $ctx.prev.result が関数 1 のレスポンスです。そこに “false”: に続けて関数 2 の結果 $ctx.result の中の件数に当たる scannedCount を取り出してマージしています。結果として、以下のデータが関数 2 のレスポンスとして関数 3 に渡されます。 { "true": xx, "false": xx } 関数 3 のリクエストマッピングテンプレート こちらは、関数 1,2 とは別のテーブルから別のデータの件数を取得します。 { "version": "2018-05-29", "operation": "Query", "query": { "expression": "#pkey = :pkey AND begins_with(#skey2, :skey2)", "expressionNames": { "#pkey": "pkey", "#skey2": "skey2" }, "expressionValues": { ":pkey": $util.dynamodb.toDynamoDBJson($context.arguments.pkey), ":skey2": $util.dynamodb.toDynamoDBJson("Red") } }, "nextToken": $util.toJson($util.defaultIfNullOrEmpty($context.arguments.after, null)), "scanIndexForward": false, "consistentRead": false, "projection": { "expression": "pkey" } } 関数 3 のレスポンスマッピングテンプレート 関数 2 から受け取ったレスポンスをここでマージします。やっていることは関数 2 と同じです。 $util.qr($ctx.prev.result.put("red", $ctx.result.scannedCount)) $util.toJson($ctx.prev.result) 結果として、以下のデータが関数 3 のレスポンスとしてパイプラインリゾルバに返されます。パイプラインリゾルバは今回の例ではそのままアプリにデータを返すので、実質関数 3 のレスポンスが最終的なレスポンスになります。 { "true": xx, "false": xx, "red": xx } (参考) AWS CloudFormation テンプレート 私はこの面倒なリゾルバの定義を AWS マネジメントコンソールで設定する気が起きず (UI がわかりにくいので)、AWS CloudFormation でデプロイしています。完全な AWS AppSync のテンプレートではありませんが、パイプラインリゾルバのところの Resources のみ抜粋して紹介します。 # パイプラインリゾルバの定義 AppSyncResolverPipeline: Type: AWS::AppSync::Resolver Properties: ApiId: !GetAtt AppSyncApi.ApiId # AppSync の API ID TypeName: Query FieldName: queryUserExamScore # AppSync のスキーマで定義したクエリの名前 Kind: PIPELINE # ここでパイプラインリゾルバであることを宣言 PipelineConfig: Functions: # 作成したい関数を処理順に並べる、関数 ID を参照 - !GetAtt FunctionUserExamScore1true.FunctionId - !GetAtt FunctionUserExamScore2false.FunctionId - !GetAtt FunctionUserExamScore3red.FunctionId RequestMappingTemplate: | {} ResponseMappingTemplate: | $util.toJson($context.result) DependsOn: - FunctionUserExamScore1true - FunctionUserExamScore2false - FunctionUserExamScore3red # 関数 1 の定義 FunctionUserExamScore1true: Type: AWS::AppSync::FunctionConfiguration Properties: ApiId: !GetAtt AppSyncApi.ApiId # DynamoDB テーブル A のデータソース名をここで参照 DataSourceName: !GetAtt AppSyncDataSourceTableA.Name Description: AppSync Function for User Exam Score Graph 1 for true FunctionVersion: 2018-05-29 Name: AppSyncFunctionUserExamScore1true RequestMappingTemplate: | { "version": "2018-05-29", "operation": "Query", "query": { "expression": "#pkey = :pkey AND #skey1 = :skey1", "expressionNames": { "#pkey": "pkey", "#skey1": "skey1" }, "expressionValues": { ":pkey": $util.dynamodb.toDynamoDBJson($context.arguments.pkey), ":skey1": $util.dynamodb.toDynamoDBJson("TRUE") } }, "nextToken": $util.toJson($util.defaultIfNullOrEmpty($context.arguments.after, null)), "scanIndexForward": false, "consistentRead": false, "projection": { "expression": "pkey" } } ResponseMappingTemplate: | $util.toJson({ "true": $ctx.result.scannedCount }) DependsOn: - AppSyncDataSourceTableA # 関数 2 の定義 FunctionUserExamScore2false: Type: AWS::AppSync::FunctionConfiguration Properties: ApiId: !GetAtt AppSyncApi.ApiId # DynamoDB テーブル A のデータソース名をここで参照 DataSourceName: !GetAtt AppSyncDataSourceTableA.Name Description: AppSync Function for User Exam Score Graph 2 for false FunctionVersion: 2018-05-29 Name: AppSyncFunctionUserExamScore2false RequestMappingTemplate: | { "version": "2018-05-29", "operation": "Query", "query": { "expression": "#pkey = :pkey AND #skey1 = :skey1", "expressionNames": { "#pkey": "pkey", "#skey1": "skey1" }, "expressionValues": { ":pkey": $util.dynamodb.toDynamoDBJson($context.arguments.pkey), ":skey1": $util.dynamodb.toDynamoDBJson("FALSE") } }, "nextToken": $util.toJson($util.defaultIfNullOrEmpty($context.arguments.after, null)), "scanIndexForward": false, "consistentRead": false, "projection": { "expression": "pkey" } } ResponseMappingTemplate: | $util.qr($ctx.prev.result.put("false", $ctx.result.scannedCount)) $util.toJson($ctx.prev.result) DependsOn: - AppSyncDataSourceTableA # 関数 3 の定義 FunctionUserExamScore3red: Type: AWS::AppSync::FunctionConfiguration Properties: ApiId: !GetAtt AppSyncApi.ApiId # DynamoDB テーブル B のデータソース名をここで参照 DataSourceName: !GetAtt AppSyncDataSourceTableB.Name Description: AppSync Function for User Exam Score Graph 3 for red FunctionVersion: 2018-05-29 Name: AppSyncFunctionUserExamScore3red RequestMappingTemplate: | { "version": "2018-05-29", "operation": "Query", "query": { "expression": "#pkey = :pkey AND begins_with(#skey2, :skey2)", "expressionNames": { "#pkey": "pkey", "#skey2": "skey2" }, "expressionValues": { ":pkey": $util.dynamodb.toDynamoDBJson($context.arguments.pkey), ":skey2": $util.dynamodb.toDynamoDBJson("Red") } }, "nextToken": $util.toJson($util.defaultIfNullOrEmpty($context.arguments.after, null)), "scanIndexForward": false, "consistentRead": false, "projection": { "expression": "pkey" } } ResponseMappingTemplate: | $util.qr($ctx.prev.result.put("red", $ctx.result.scannedCount)) $util.toJson($ctx.prev.result) DependsOn: - AppSyncDataSourceTableB まとめ いかがでしたでしょうか。 今回のサンプルでは、それぞれの関数の結果を順番にマージしていくだけの簡単な直列処理でしたが、前の関数の結果を次の関数のクエリのパラメータに使用することもできます。その場合はリクエストマッピングテンプレートの中で前の関数のレスポンス $ctx.prev.result を使用します。 それにより通常 DynamoDB への単体のクエリでは実現できない、テーブルの結合に近いことが実はできます。まあ同じことやるにしても Lambda 関数書けば普通にできるんですが、VTL の方が処理が速いのと Lambda 関数が乱立しなくていいなぁと思って極力私は VTL を使っています。 本記事が皆様のお役に立てれば幸いです。
こんにちは、SCSK株式会社の小寺崇仁です。 先日Zabbixの7.0がリリースされました。 Zabbix7.0では、様々な機能追加、改善が行われております。 詳細は以下をご確認ください。 What's new in Zabbix 7.0 LTS www.zabbix.com はじめに 今回は7.0で行われた性能改善について検証をしていきたいと思います。 公式HPでは以下の記載があります。 Improved data collection speed and scalability ・Faster metric polling for agent, SNMP and HTTP checks ・Next metric can now be polled before waiting for a response from previously requested metric 今までは、エージェント監視、SNMPエージェント監視、HTTPエージェント監視は「poller」プロセスで監視が行われておりましたが、「agent poller」「snmp poller」「http poller」に分割されたようです。 また、値を取得する際に、リクエスト送信からレスポンス受信までの間はプロセスが待機をしており、ビジー率上昇をしておりましたが、非同期で処理を行うように改善されたようです。 検証環境について 6.0と7.0のZabbixサーバからSNMPDのインストールされたサーバーに対してSNMPポーリング監視を行い、稼働状況を確認します。 サーバ情報 項目 Zabbix6.0 Zabbix7.0 SNMPサーバ OS RHEL 9.4 RHEL 9.4 RHEL 9.4 Zabbixバージョン 6.0.30 7.0.0 ー SNNPDバージョン ー ー 5.9.1 インスタンスタイプ t2.medium（2vcpu,４GB） t2.medium（2vcpu,４GB） t2.medium（2vcpu,４GB） ディスク 30GB (gp3 3000iops) 30GB (gp3 3000iops) 30GB (gp3 3000iops) Zabbixのパラメータ情報 項目 Zabbix6.0 Zabbix7.0 備考 StartPollers 5 5 デフォルト=5 StartSNMPPollers ー 10 7.0新機能 MaxConcurrentChecksPerPoller ー 1000 7.0新機能 CacheSize 512M 512M 検証時に不足 TrendCacheSize 256M 256M 検証時に不足 ※上記以外がデフォルトパラメータを使用 ※Mariadbはデフォルトパラメータを使用 監視設定 インターフェースのステータスを取得するテンプレートを作成しました。 インターフェースは50個ある想定で50アイテム作成しています。 ホストを1000台登録し、１のテンプレートを適用しました。 SNMPインターフェースのBulkリクエストは検証のため無効にしました。 アイテムの取得間隔は1分です。 7.0の新機能を使うには、アイテムのOIDは「get[OUID]」「walk[OID,OID]」と記入する必要があります。 Zabbixの状態としては以下の通りです。 項目 Zabbix6.0 Zabbix7.0 備考 監視対象ホスト 1002 1002 アイテム数 50175 50180 1秒あたりの監視項目数(NVPS) 835.86 835.91 検証結果１（通常監視） Zabbix6.0 Pollerプロセスの使用率は平均11％ キューなし Zabbix7.0 SNMPPollerプロセスの使用率は1%前後 キューなし 結果＆考察 Zabbix7.0でSNMPPollerプロセスの使用率がほぼ上がらず、とても効率よく処理ができていると思われます。 検証１はZabbixサーバとSNMPサーバが同じVPCにあり、SNMPの値の取得が一瞬で終わっています。検証2では実際の環境に近い形で検証しします。 検証２（レスポンスの悪いOIDを追加する） 実際の監視では、レスポンスの悪いNW機器があり、待機時間によりPollerプロセスの使用率を上昇させていることがあると思います。 検証2では、レスポンスの悪いカスタムOIDを追加し検証します。 /etc/snmp/snmpd.confに以下を追記します。 view systemview included .1 extend sleep /tmp/test.sh /tmp/test.shの内容は以下となります。2秒待機してから値を返却します。 #!/bin/sh sleep 2 echo 11 新しく作成した監視のアイテムを作成します。 各ホストにアイテムを1つ（1000アイテム）追加しています。 Zabbix6.0 応答が遅いOIDが追加されたことでPollerプロセスの使用率が50%弱まで上昇しました。 Zabbix7.0 SNMPサーバ側が負荷に耐えられなくなったため、MaxConcurrentChecksPerPollerを1000→100に変更しました。 SNMPPollerプロセスの使用率は1%前後のままから上昇しませんでした。（値を取得するまで待機していない事が分かります） 値が正しく取得できているか不安になりますが、問題なく取得できています。 総括 データ収集処理は非同期処理に変更され、値の取得を待機しなくなったため、パフォーマンスが劇的に改善しました。 1プロセスのリクエスト数（MaxConcurrentChecksPerPoller）が設定できるようになり、効率化されている。 アイテム作成時にOIDの書き方に注意が必要です。（get[],walk[]をつける必要がある） 最後に 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 SCSK Plus サポート for Zabbix SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。 最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。 ツイッターアカウント： www.youtube.com ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ 【公式】SCSK Zabbix (@SCSK_Zabbix) / Twitter SCSKが提供するZabbixサービスのオフィシャルアカウントです。 #Zabbix #SCSKPlusサポートforZabbix #監視 #SCSK twitter.com
こんにちは、SCSK株式会社の中野です。 2024年6月に最新バージョンであるZabbix 7.0 LTSがリリースされました。 Zabbix 7.0の新機能をいろいろ試しておりまして、今回は多要素認証機能（Duo認証）の利用方法をご紹介いたします。 多要素認証機能（TOTP）の利用方法は前回の記事「 多要素認証機能 (TOTP) を利用してみた 」にて紹介しております。 宜しければご覧ください。 Zabbixとは まずはZabbixの説明を簡単にさせていただきます。 Zabbixは、エンタープライズ対応のオープンソース統合監視ツールです。 サービスやそれを支える ITシステム(サーバ、ネットワーク機器等)の状態を把握し、障害の予兆やサービスへ影響を及ぼす事象が発生した際に、システム管理者やオペレータに通知を行うオープンソースの統合監視ソリューションです。 数万デバイス規模のエンタープライズ環境でも多数の稼動実績を誇っています。 Zabbixの詳細情報については、下記リンクよりご確認ください。 Zabbix :: The Enterprise-Class Open Source Network Monitoring Solution ZabbixはITインフラストラクチャ・コンポーネントの可用性やパフォーマンスを監視するためのエンタープライス向けソフトウェアです。Zabbixはオープンソース・ソフトウェアとして開発されており、無料でダウンロードいただくことが可能です。 www.zabbix.com 多要素認証機能 Zabbix7.0 LTSは多要素認証により、Zabbix Webインターフェースへのアクセスのセキュリティが強化されております。 認証方法としては、以下２つの認証が利用可能です。 ・ワンタイムパスワード（TOTP） ・Duo認証 今回はDuo認証を用いて、多要素認証を実装していきたいと思います。 ※Duo認証は多要素認証（MFA）を含む一連のセキュリティ機能を提供してます。また、シングルサインオン（SSO）やデバイスの信頼性チェック、適用型アクセスポリシーなど、セキュリティを強化しながらユーザビリティを維持するための追加機能が提供されていることが特徴です。 多要素認証機能（Duo認証）を実装 (事前準備) Duo認証を利用するためには、以下の事前準備を実施しておく必要がございます。 ・Duo Mobileアプリのインストール ・Zabbixサーバへphp-curlのインストール ・HTTPSでのZabbixへのアクセス ※ブラウザでZabbixへアクセスする際に、IPアドレスではなくホスト名でアクセスする必要があります。 ・Duoサーバへのアウトバウンド通信の許可設定 ・Webサーバでコンテンツセキュリティポリシーを有効にしている場合は、CSPディレクティブに「duo.com」を追加 また、Duo上でDashboard/Applications/Web SDK上から以下の認証情報をメモしてください。 ・Client ID ・Client secret ・API hostname 多要素認証機能（Duo認証）を実装 (Zabbixサーバ側の設定) ZabbixでDuo認証を利用する方法を記載します。 まずは「ユーザ」/「認証」/「多要素認証(MFA)の設定」で「多要素認証の有効化」にチェックを入れます。 新しい認証方法を「追加」します。 タイプ：「Duoユニバーサルプロンプト」 名前：任意の文字列 APIホスト名：上記でメモした「API hostname」を入力 クライアントID：上記でメモした「Client ID」を入力 クライアントシークレット：上記でメモした「Client secret」を入力 続いて、「ユーザ」/「ユーザーグループ」上で多要素認証を上記の多要素認証(MFA)方式名に変更し「追加」をクリックします。 以下の例だと「Duo」といった方式名にしてます。 以上でZabbix側の多要素認証機能の設定は完了です。 多要素認証機能（Duo認証）を実装 (ユーザー側の設定) 上記で設定したグループに所属するユーザーでZabbix Webインターフェースへのアクセスする際に Duoにリダイレクトされるので、「Get Started」をクリックし、Duoのセットアップをしていきます。 追加するデバイスを選択します。今回は「Duo Mobile」を選択してます。 電話番号の記載をした後に、「Continue」をクリックします。 Duo Mobileをダウンロードしていない場合はダウンロードを実施し、「Next」をクリックします。 Duo Mobile上でQRコードを読み込みます。 成功すると、Duo Mobileを追加できた旨が表示されるので「Continue」をクリックします。 他のデバイスを追加する画面が出ましたが、今回はスキップ「Skip for now」しました。 セットアップが完了し、「Log in with Duo」をクリックします。 以上でユーザー側の多要素認証機能の設定も完了です。 次回以降、Duo Mobileアプリが提供する方法（Duo Push、パスコード、バイバスコードなど）でログインすることが可能になります。 最後に Zabbix 7.0の新機能であるDuoによる多要素認証はTOTP同様に簡単に実装することができ、よりセキュリティの強化を図ることが可能になりました。 IDとパスワードだけでは不十分であると感じる場合は、多要素認証機能の実装をご検討いただければと思います。 また今回説明した機能の他にも、Zabbix7.0はプロキシ冗長化構成や分散監視の実装、スクリーンショットも取得ができる新しいWeb監視、監視処理の効率化によるパフォーマンスの大幅な向上やダッシュボードの新しいウィジェットなど、非常に多くの機能を実装しております。 他の新機能も試してみて情報を発信していきたいと思います。 最後まで読んでいただき、ありがとうございました。
こんにちは、SCSK株式会社の小寺崇仁です。 このブログではZabbixのデータベース内部構成について紹介をしたいと思ってます。 第1弾としてホスト設定を取得するSQLを作成してみます。 はじめに 私はZabbixの構築を主に担当しています。最近はZabbixと外部システムを連携しているお客様が増加傾向にあると感じています。外部システムと連携をしたいお客様にはサポート範囲内である、ZabbixAPIを使用した方法を案内しています。 しかし、Zabbixはオープンソースであり、RDBMSを使用しているため、DBを直接参照することが可能です。DBの知識がある方であれば、容易にデータ抽出ができますので、表の構造とサンプルSQLを記事にしたいと思います。 注意事項 Zabbixのデータベース内部に関するは情報が少ないです。そのため私が個人的にDBを解析して情報発信を行う非公式情報になります。 当社ではZabbixの有償サポートを実施しております。Zabbixのデータベース内部に関する問い合わせはサポート範囲に含まれておらず、本ブログの内容をサポート宛に問い合わせをいただいても回答ができません。 個人的に作成したSQLです。自己責任でご利用ください。間違っていた場合イベント等でこっそり教えてください。 テーブル定義 hosts ホスト情報が格納されるメインのテーブルです。 Field 日本語名称 Type Null Key Default Extra hostid ホストID bigint unsigned NO PRI NULL host ホスト名 varchar(128) NO MUL name 名前 varchar(128) NO MUL description 説明 text NO NULL templateid テンプレートID bigint unsigned YES MUL NULL flags フラグ int NO 0 status ステータス int NO MUL 0 ０：有効 １：無効 ３：テンプレート maintenance_status メンテナンスステータス int NO 0 ipmi_authtype IPMI認証タイプ int NO -1 ipmi_privilege IPMI権限 int NO 2 ipmi_username IPMIユーザー名 varchar(16) NO ipmi_password IPMIパスワード varchar(20) NO maintenanceid メンテナンスID bigint unsigned YES MUL NULL maintenance_type メンテナンスタイプ int NO 0 maintenance_from メンテナンス開始 int NO 0 tls_connect TLS接続 int NO 1 tls_accept TLS受け入れ int NO 1 tls_issuer TLS発行者 varchar(1024) NO tls_subject TLSサブジェクト varchar(1024) NO tls_psk_identity TLS PSKアイデンティティ varchar(128) NO tls_psk TLS PSK varchar(512) NO proxy_hostid プロキシホストID bigint unsigned YES MUL NULL – proxy_address プロキシアドレス varchar(255) NO auto_compress 自動圧縮 int NO 1 discover ディスカバー int NO 0 lastaccess 最終アクセス int NO 0 custom_interfaces カスタムインターフェース int NO 0 uuid UUID varchar(32) NO name_upper 名前（大文字） varchar(128) NO MUL hosts_gropus ホストとグループの関連付けが保存されるテーブルです。 Field 日本語名称 Type Null Key Default Extra hostgroupid ホストグループID bigint unsigned NO PRI NULL hostid ホストID bigint unsigned NO MUL NULL groupid グループID bigint unsigned NO MUL NULL hstgrp ホストグループが保存されるテーブルです。 Field 日本語名称 Type Null Key Default Extra groupid グループID bigint unsigned NO PRI NULL name ホストグループ名 varchar(255) NO MUL internal インターナル int NO 0 flags フラグ int NO 0 uuid UUID varchar(32) NO interface インターフェースに関するテーブルです。 Field 日本語名称 Type Null Key Default Extra interfaceid インターフェースID bigint unsigned NO PRI NULL hostid ホストID bigint unsigned NO MUL NULL main メイン int NO 0 type タイプ int NO 1 useip IP使用 int NO 1 ip IPアドレス varchar(64) NO MUL 127.0.0.1 dns DNS varchar(255) NO port ポート varchar(64) NO 10050 available 利用可能 int NO MUL 0 error エラー varchar(2048) NO errors_from エラー発生元 int NO 0 disable_until 無効期限 int NO 0 サンプルSQL ホスト取得 SELECT h.hostid ,h.host ,h.name as 表示名 ,CASE h.status WHEN 1 THEN '無効' ELSE '有効' END AS ステータス FROM hosts h WHERE h.status in (0,1); ホスト+ホストグループ SELECT h.hostid ,h.host ,h.name as 表示名 ,CASE h.status WHEN 1 THEN '無効' ELSE '有効' END AS ステータス ,hg.name FROM hosts h LEFT JOIN hosts_groups hgs ON h.hostid = hgs.hostid LEFT JOIN hstgrp hg ON hgs.groupid = hg.groupid WHERE h.status in (0,1) ホスト+インターフェース SELECT h.hostid AS ホストID ,h.host as ホスト ,h.name as 表示名 ,CASE h.status WHEN 1 THEN '無効' ELSE '有効' END AS ステータス ,CASE i.type WHEN 1 THEN 'Zabbixエージェント' WHEN 2 THEN 'SNMP' WHEN '3' THEN 'IPMI' WHEN '4' THEN 'JAVA' END AS タイプ ,CASE i.main WHEN 1 THEN 'メイン' END AS メイン ,CASE i.useip WHEN 0 THEN 'DNS' ELSE 'IP' END AS 接続方法 ,i.ip AS IPアドレス ,i.dns AS DNS名 ,i.port AS ポート ,s.version AS SNMPバージョン ,s.community AS SNMPコミュニティ ,CASE s.bulk WHEN 1 THEN '有効' END AS SNMPバルク FROM hosts h LEFT JOIN interface i ON h.hostid = i.hostid LEFT JOIN interface_snmp s ON i.interfaceid = s.interfaceid WHERE h.status in (0,1) 最後に 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 SCSK Plus サポート for Zabbix SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。 最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。 ツイッターアカウント： www.youtube.com ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ 【公式】SCSK Zabbix (@SCSK_Zabbix) / Twitter SCSKが提供するZabbixサービスのオフィシャルアカウントです。 #Zabbix #SCSKPlusサポートforZabbix #監視 #SCSK twitter.com
こんにちは、SCSK株式会社の中野です。 2024年6月4日に最新バージョンであるZabbix 7.0 LTSがリリースされました。 Zabbix 7.0の新機能として新たに多要素認証がサポートされましたので、機能の利用方法をご紹介いたします。 Zabbixとは まずはZabbixの説明を簡単にさせていただきます。 Zabbixは、エンタープライズ対応のオープンソース統合監視ツールです。 サービスやそれを支える ITシステム(サーバ、ネットワーク機器等)の状態を把握し、障害の予兆やサービスへ影響を及ぼす事象が発生した際に、システム管理者やオペレータに通知を行うオープンソースの統合監視ソリューションです。 数万デバイス規模のエンタープライズ環境でも多数の稼動実績を誇っています。 Zabbixの詳細情報については、下記リンクよりご確認ください。 Zabbix :: The Enterprise-Class Open Source Network Monitoring Solution ZabbixはITインフラストラクチャ・コンポーネントの可用性やパフォーマンスを監視するためのエンタープライス向けソフトウェアです。Zabbixはオープンソース・ソフトウェアとして開発されており、無料でダウンロードいただくことが可能です。 www.zabbix.com 多要素認証機能 Zabbix7.0 LTSは多要素認証により、Zabbix Webインターフェースへのアクセスのセキュリティが強化されております。 認証方法としては、以下２つの認証が利用可能です。 ・ワンタイムパスワード（TOTP） ・Duo認証 今回はワンタイムパスワード（TOTP）を用いて、多要素認証を実装していきたいと思います。 ※TOTPはTime-based One-Time Passwordの略称です。一度しか利用できない「ワンタイムパスワード」の一種であり、時間に基づいた乱数からパスワードを生成します。生成されるパスワードは30秒ほどで切り替わるため、不正アクセスなどのリスクを抑えられるのが特徴です。 多要素認証機能（TOTP）を実装 (Zabbixサーバ側の設定) Zabbixでワンタイムパスワード（TOTP）を利用する方法を記載します。 まずは「ユーザ」/「認証」/「多要素認証(MFA)の設定」で「多要素認証の有効化」にチェックを入れます。 新しい認証方法を「追加」します。 タイプ：「TOTP」 or 「Duoユニバーサルプロンプト」 名前：任意の文字列 ハッシュ関数：「SHA-1」or 「SHA-256」 or 「SHA-512」 認証コード長：「6」 or 「8」 続いて、「ユーザ」/「ユーザーグループ」上で多要素認証を上記の多要素認証(MFA)方式名に変更し「追加」をクリックします。 以下の例だと「MFA」といった方式名にしてます。 以上でZabbix側の多要素認証機能の設定は完了です。 多要素認証機能（TOTP）を実装 (ユーザー側の設定) 上記で設定したグループに所属するユーザーでZabbix Webインターフェースへのアクセスする際に 以下のQRコードが出てきますので、QRコードをスキャン、まやはGoogle Authenticatorアプリに秘密キーを入力し アプリで生成された認証コードを「Vertification code」に入力して「サインイン」ボタンをクリックします。 設定が完了後、次回のログイン時からワンタイムパスワード（TOTP）を使用したログインが可能になります。 以上でユーザー側の多要素認証機能の設定も完了です。 最後に Zabbix 7.0の新機能である多要素認証は簡単に実装することができ、よりセキュリティの強化を図ることが可能になりました。 IDとパスワードだけでは不十分であると感じる場合は、多要素認証機能の実装をご検討いただければと思います。 また今回説明した機能の他にも、Zabbix7.0はプロキシ冗長化構成や分散監視の実装、スクリーンショットも取得ができる新しいWeb監視、監視処理の効率化によるパフォーマンスの大幅な向上やダッシュボードの新しいウィジェットなど、非常に多くの機能を実装しております。 他の新機能も試してみて情報を発信していきたいと思います。 最後まで読んでいただき、ありがとうございました。
こんにちは、広野です。 AWS AppSync を使用したアプリケーションを開発する機会があり、リゾルバ、主に VTL の書き方に関してまとまった知識が得られたので紹介します。前回からの続きもので、今回は引数内のフラグ条件により実行させる処理 (オペレーション) を分岐する方法を紹介します。 本記事では、VTL の書き方にフォーカスしています。ご了承ください。 AWS AppSync、リゾルバ、VTL の説明については以下の記事をご覧下さい。 AWS AppSync リゾルバ (VTL) の書き方サンプル No.1 - Amazon DynamoDB GetItem Amazon DynamoDB に VTL で GetItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.01.09 AWS AppSync リゾルバ (VTL) の書き方サンプル No.2 – Amazon DynamoDB BatchGetItem Amazon DynamoDB に VTL で BatchGetItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.01.19 AWS AppSync リゾルバ (VTL) の書き方サンプル No.3 – Amazon DynamoDB Query Amazon DynamoDB に VTL で Query をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.02.26 AWS AppSync リゾルバ (VTL) の書き方サンプル No.4 - Amazon DynamoDB PutItem Amazon DynamoDB に VTL で PutItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.02.26 AWS AppSync リゾルバ (VTL) の書き方サンプル No.5 – Amazon DynamoDB UpdateItem Amazon DynamoDB に VTL で UpdateItem をかけるときの基本的な書き方を紹介します。 blog.usize-tech.com 2024.02.27 AWS AppSync を使って React アプリからキックした非同期ジョブの結果をプッシュ通知で受け取る 非同期ジョブを実行した後、結果をどう受け取るか？というのは開発者として作り込み甲斐のあるテーマです。今回は React アプリが非同期ジョブを実行した後に、AWS AppSync 経由でジョブ完了のプッシュ通知を受け取る仕組みを紹介します。 blog.usize-tech.com 2022.12.01 やりたいこと 例えば、AWS AppSync から以下のリクエストを受けたとします。Amazon DynamoDB には適切なデータがある想定です。テーブル名はリゾルバの別の設定 (Data Source) で行います。 引数となるパラメータ： status の中に true/false の Boolean 値、パーティションキー pkey、ソートキー skey、属性 attr 今回は受け取った status をフラグとして、 true の場合はパーティションキーとソートキー、属性をそのまま PutItem し、 false の場合はパーティションキーとソートキーに該当するデータを DeleteItem します。 Amazon DynamoDB に命令する VTL リクエストマッピングテンプレート { "version": "2018-05-29", "operation": #if($context.arguments.status) "PutItem" #else "DeleteItem" #end, #if($context.arguments.status) "key": { "pkey": $util.dynamodb.toDynamoDBJson($pkey), "skey": $util.dynamodb.toDynamoDBJson($skey) }, "attributeValues": { "attr": $util.dynamodb.toDynamoDBJson($context.arguments.attr) } #else "key": { "pkey": $util.dynamodb.toDynamoDBJson($pkey), "skey": $util.dynamodb.toDynamoDBJson($skey) } #end } operation の部分に、上記のように if 分岐を書くことで、オペレーションを PutItem にするか DeleteItem にするか、1行で分けることができます。 当然、PutItem のときと DeleteItem のときで DynamoDB に渡す “key” の項目が異なりますので、そこも if 分岐を書きます。 簡単な処理であれば、1つの VTL で引数によって処理を変えられるので、使いようによっては開発を効率化できると思います。もちろん他のオペレーションにも応用できます。 レスポンスマッピングテンプレート 結果は配列に格納されます。戻ってきたデータをそのままアプリ側に戻す書き方です。 $utils.toJson($context.result) VTL に関しては以下の AWS 公式ドキュメントも必要に応じてご確認ください。 Resolver mapping template reference for DynamoDB - AWS AppSync Resolver Mapping Template Reference for DynamoDB for AWS AppSync. docs.aws.amazon.com まとめ いかがでしたでしょうか。 VTL 内では if 分岐を自由に書けるので、今回の例に限らずやりたいことを試してみて頂けたらと思います。 本記事が皆様のお役に立てれば幸いです。
どうも、SCSK株式会社の2023 Japan AWS Jr. Championsの齋藤です。 2024年4月30日を持ちまして、2023 Japan AWS Jr. Championsの任期が満了しました。 Jr.Championsという制度の第一期生ということで、１年間活動してきた記録や感想をこのブログで記載します。 2023 Japan AWS Jr. Championsの活動について そもそもJr. Championsとは何なのか？という方は下記サイトをご参照ください。 2023 Japan AWS Jr. Champions の発表 | Amazon Web Services 皆様、こんにちは！PSA (Partner Solutions Architect) の Yukki です。「 aws.amazon.com 2023 Japan AWS Jr. Championsは、大きく分けて２つの種類の活動特性があったと個人的に考えております。 コミュニティ活動としての特性 公人（インフルエンサー）としての特性 コミュニティ活動としての特性 2023 Japan AWS Jr. Championsでは、毎月約３つのコミュニティ活動があり、他社のJr.Championsなどと交流することができました。 AWS社主催のJr. Champions限定MeetUp Jr. ChampionsによるLTが多め。月によってはWorkshopやJAM大会など実施。 Jr. Champions有志による勉強会 Jr. Champions内のみで開催される有志によるLT会。 Jr. Champions有志によるTopEngineers招待の勉強会 TopEngineersを招待して、Jr. ChampionsによるLTを実施。 公人（インフルエンサー）としての特性 2023 Japan AWS Jr. Championsという名前を背負って公人として活動し、AWSの良さを社内外に幅広くアピールして、周りに影響を与えていく、つまりインフルエンサーのような活動を実施することが求められました。 例えば、JAWSなどの社外勉強会の登壇、社内コミュニティのリード、ブログの執筆、書籍の執筆などです。 これに関しては、自分で機会を探して、自ら手を挙げて積極的に発信をしていく必要がありました。 私のこれまでの活動記録 ２つの活動特性がある「2023 Japan AWS Jr. Champions」として、どのような活動をしてきたか書いていきます。 社内での登壇 社内での登壇は下記２件を実施しました。 社内勉強会でのLT 社内で開催された勉強会で、私はAWSハンズオン教材に関する登壇を実施しました。 開催された勉強会が「AWSの勉強法について」のようなテーマだったため、私なりにハンズオンを用いた学習方法のおすすめポイントや、おすすめ教材などの紹介を実施いたしました。 新人研修での登壇 昨年度の自分が所属する部門の新人研修にて、Jr.Championsとして登壇をいたしました。 Jr.Championsは若手が目指す制度という特性があるので、同制度のメリットや、なるための心得といったことを新人向けへ話してきました。登壇後の新人からのアンケートでも、好意的なフィードバックをいただけたことは大変嬉しかったです。 社外での登壇 JAWS-UG東京 ランチタイムLT会 #5 2023年11月に開催されたJAWS-UGのランチタイム会に登壇をしてきました。 テーマは、「AWS上のサイバー攻撃に気をつけよう！」という内容で、よくあると感じるAWS上のサイバー攻撃の事例とその対策についてLTをしてきました。 初めて公の場でのLT登壇をしましたが、オンラインでのLTに慣れていたので、そこまで実感が湧かなかったです（笑） JAWS-UG東京 ランチタイムLT会 #5 (2023/11/21 12:00〜) JAWS-UG東京のリブート企画として開催したフリーテーマのランチLT会、好評だったので毎月継続します！ オンラインなので全国どこからでも参加OK。お昼食べながら気軽にご参加ください👍 # アジェンダ 1時間以内でサクッと終わる予定です！ ... jawsug.connpass.com グローバルクラウドアーキテクトコミュニティJapan Meetup 2023年11月にNTTデータ様主催のグローバルイベントにて、LT登壇を実施いたしました。 NTTデータ様の海外法人（スペイン、イタリア、ドイツ）のAWS Ambassadorの方々が来日し、各国のコミュニティ活動の事例などをお話しされていました。 グローバルクラウドアーキテクトコミュニティJapan Meetup開催！ NTTDATAでは、技術力の最大化に向けて、クラウド技術に関するグローバル連携の強化を推進している。2022年の夏、コロナ禍の最中にスタートしたグローバルクラウドアーキテクトコミュニティ（Global Cloud Architect Com... www.nttdata.com また、イベントの中で、参加者の中から英語によるLT大会がありましたので、そちらに立候補してきました。 初めての英語のLTで、完全にカンペ頼りなLTになってしまいましたが、貴重な体験となったことは間違い無いです！ JAWS DAYS 2024 2024年3月に東京・池袋サンシャインシティで開催されJAWS DAYS 2024に、ランチタイムスポンサーとして登壇してきました。 お昼の中の15分でLTができるという枠なので、このTechHarmonyのおすすめ記事を紹介するという内容で、弊社AWS Ambassadorと登壇してきました。 本イベントでは、他の登壇者や、ボランティアの中にもJr.Championsの方々が参加しており、Jr.Championsが登壇するセッションには他のJr.Championsが応援しにいくなど、Jr.Championsの強いつながりを実感したイベントでありました！ オンサイトイベントでのLTは慣れておらず、発表は大変緊張しましたが、この1年で1番楽しかったイベントで間違いないです！！ コロナ世代で社会人1日目からフルリモート勤務を経験した身としては、オンサイトでのコミュニティ活動の良さを実感したイベントですので、来年も同様のイベントに参加したいと思っています！！ JAWS DAYS 2024 JAWS DAYS 2024 Official HP jawsdays2024.jaws-ug.jp Jr. Championsコミュニティでの登壇 前述の「2023 Japan AWS Jr. Championsの活動について」で記載したJr. Championsのコミュニティ活動においても、LT登壇などを実施してきました。 AWS社主催のJr. Champions限定MeetUpでの登壇 前述した「①コミュニティ活動としての特性」の中の①に該当するイベントで登壇をしてきました。 内容としては、「AWS上のサイバー攻撃に気をつけよう！」という内容です。社外登壇のJAWS-UGのランチタイム会とほとんど同様の内容ですが、登壇としてはこちらの方が先です。 Jr.Champions内のイベントで発表した際、好意的なフィードバックなどをいただいたため、社外イベントであるJAWSへの登壇を決めるきっかけになりました。 中々社外のイベントに出る勇気がなかったのですが、Jr.Champions内のイベントというクローズドな場で発表して手応えを感じたため、出てみようというきっかけを作ることができたと考えております。 TopEngineers招待の勉強会 前述した「①コミュニティ活動としての特性」の中の③に該当するイベントで登壇をしてきました。 内容としては、「AWSサポートの使い方」という内容で、AWSサポートには適切の適切な使い方と、アンチパターンなどを発信しました。AWSサポートの使い方について詳しく話をする人はそうそういないようで珍しがられました（笑） ちなみに、このTopEngineers招待の勉強会は、基本オンラインでの開催ですが、弊社の本社がある東京都江東区豊洲周辺の企業はオンサイトで集まって一緒に勉強会を聞くという「 豊洲会 」を開催しております。 私が登壇した際は、弊社の豊洲本社に社内外含めて30人ほど招いて開催をいたしました！ 1年を振り返っての感想 Jr.Championsの1年は、大変多くの人や機会に恵まれた1年だと感じております。 多くのイベントに参加し、社内外の多くの人と交流できたことは、私のエンジニア人生でこれから何がしたいのかを考えるいい機会になりました。 この1年で自分には技術的な経験が不足していると感じたのと、これからもっと技術力を磨き、技術の素晴らしさを世に発信できる人になりたいと考えたため、4月から新しい仕事内容に従事し、技術的な研鑽を日々行っております。 Jr.Championsを卒業した後も、技術を勉強し、それを発信し続け、業界をリードできるような人材になれるように努力していきます。 これからJr.Championsになる方へ 私からこれからJr.Championsになる方へ下記2点をすることをお勧めします。 自己分析をすること とにかく発信すること Jr.Championsになって、積極的な発信を求められる立場になりましたが、私自身技術的な仕事をしているわけではなかったのと、周りのJr.Championsの方が強そうに見えて、どのような発信をすれば良いか悩んだ時期も少しだけありました。 しかし、周りのJr.Championsの方が積極的に発信している姿勢を見て感化させられた部分があり、自分の詳しい分野は何か？強みは何か？というのを考えて、徐々に発信活動を増やしていきました。 発信をしてみると、周りの方からは「勉強になりました！」と言ってくださる方も多く、非常にやりがいを感じるようになりました。 そして、発信活動を増やしていくと、周りの方々からお声がけをいただいてイベントに登壇する機会をいただけるなど、周りからの視線も変わってきて、多くの機会や人との出会いに恵まれるようになります。 そのため、これからJr.Championsになる方は、自分の発信できる領域が何かというのを考えて、とにかくなんでも良いので発信してみるといいと思います！ 1年という役割の期間は、長いようで短いと感じており、悩んでた時期がもったいなかったなと今は考えておりますので、選ばれた方は貴重な1年をどう過ごすのかをしっかり考えて過ごしていくことをお勧めします！
こんにちは、SCSK株式会社の中野です。 2024年6月4日に最新バージョンであるZabbix 7.0 LTSがリリースされましたので、 早速インストールしてみたいと思います。 今回は、AWS環境上にRHEL9.3を立てて、その中にZabbix（Ver.7.0）をインストールしてみました。 Zabbixとは まずはZabbixの説明を簡単にさせていただきます。 Zabbixは、エンタープライズ対応のオープンソース統合監視ツールです。 サービスやそれを支える ITシステム(サーバ、ネットワーク機器等)の状態を把握し、障害の予兆やサービスへ影響を及ぼす事象が発生した際に、システム管理者やオペレータに通知を行うオープンソースの統合監視ソリューションです。 数万デバイス規模のエンタープライズ環境でも多数の稼動実績を誇っています。 Zabbixの詳細情報については、下記リンクよりご確認ください。 Zabbix :: The Enterprise-Class Open Source Network Monitoring Solution ZabbixはITインフラストラクチャ・コンポーネントの可用性やパフォーマンスを監視するためのエンタープライス向けソフトウェアです。Zabbixはオープンソース・ソフトウェアとして開発されており、無料でダウンロードいただくことが可能です。 www.zabbix.com 導入手順 早速、Zabbix7.0を導入していきたいと思います。今回の構成は以下とさせていただきます。 ZABBIX VERSION: 7.0 LTS OS DISTRIBUTION: Red Hat Enterprise Linux OS VERSION: 9 DATABASE: MySQL WEB SERVER: Apache SELinux: 無効 Firewalld: 無効 関連パッケージのインストール、DB初期設定 Zabbixをインストールする前に、MySQLとApacheをインストールしておきます。 # 関連パッケージのインストール dnf install mysql-server httpd # データベースを起動 systemctl start mysqld systemctl enable mysqld 続いて、Zabbix用データベースを作成します。 DB名、アカウント名やパスワード環境に応じて設定いただければと思います。 # DBへの接続 mysql -uroot -p Enter password: （MySQLのrootアカウントのパスワードを入力） # DB、アカウントを作成 > CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin; > CREATE USER zabbix@localhost IDENTIFIED BY 'zabbix'; > GRANT all privileges ON zabbix.* TO zabbix@localhost; > SET global log_bin_trust_function_creators = 1; > exit Zabbixサーバのインストール Zabbixをインストールする前に、専用のリポジトリを追加します。 # 専用リポジトリのインストール rpm -Uvh https://repo.zabbix.com/zabbix/7.0/rhel/9/x86_64/zabbix-release-7.0-2.el9.noarch.rpm # キャッシュのクリア dnf clean all # Zabbixサーバのインストール dnf install zabbix-server-mysql zabbix-web-mysql zabbix-web-japanese zabbix-apache-conf zabbix-sql-scripts zabbix-agent 続いて、Zabbix用データベースへ初期データをインポートします。 # DBへ初期データをインポート zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql --default-character-set=utf8mb4 -uzabbix -p zabbix Enter password: （MySQLのzabbixアカウントのパスワードを入力） 初期データのインポート後、log_bin_trust_function_creatorsを無効にします。 # DBへの接続 mysql -uroot -p Enter password: （MySQLのrootアカウントのパスワードを入力） > SET global log_bin_trust_function_creators = 0; > exit その後、Zabbixサーバーの設定と起動を行います。 # 各パラメータ設定 /etc/zabbix/zabbix_server.conf DBHost=localhost DBName=zabbix DBUser=zabbix DBPassword=zabbix # サービスの起動 systemctl start zabbix-server zabbix-agent httpd php-fpm systemctl enable zabbix-server zabbix-agent zabbix-agent httpd php-fpm Zabbix WEBコンソールへのアクセス Zabbixのインストールは完了しましたので、Webコンソール上でセットアップしていきます。 ブラウザを立ち上げて、以下にアクセスします。 http://xxx.xxx.xxx.xxx/zabbix xxxには、今回構築したIPアドレスを入れてください。例えば、もしZabbixサーバーのIPアドレスが192.168.0.1なら、アドレスバーには”http://192.168.0.1/zabbix”と入力します。 言語を【日本語（ja_JP）】に変更して、【次のステップ】をクリックします。 すべての項目が「OK」になっていることを確認し、【次のステップ】をクリックします。 パスワード欄に先ほど設定したZabbixDBのパスワードを入力し、【次のステップ】をクリックします。 タイムゾーン欄で【(UTC+9:00) Asia/Tokyo】を選択、Zabbixサーバ名を記入し、【次のステップ】をクリックします。 設定内容に問題がなければ、【次のステップ】をクリックします。 【終了】をクリックすると、以下のようなログイン画面が表示されます。 初期状態でユーザーが登録されているので、以下のユーザー名・パスワードでログインします。 ユーザ名：Admin パスワード：zabbix ログインすると、WEBコンソール画面が表示されます。 以上でZabbixのインストールは完了です。 最後に Zabbix7.0は以前のバージョンと比較的に変わりなく、インストールすることができました。 Zabbix7.0はプロキシ冗長化構成や分散監視の実装、スクリーンショットも取得ができる新しいWeb監視、監視処理の効率化によるパフォーマンスの大幅な向上やダッシュボードの新しいウィジェットなど、非常に多くの機能を実装しているとのことです。 今回はインストールのみでしたが、新機能も試してみて情報を発信していきたいと思います。 最後まで読んでいただき、ありがとうございました。
Prisma Cloudでは、クラウドインフラストラクチャ全体の設定ミスやリスクを監視するために”ポリシー”と呼ばれるものを使用します。 ポリシーには複数のポリシータイプが存在しますが、その中でもAttackPathポリシーは重要度が高いポリシーとなっています。 今回は、AttackPathポリシーの重要性と検知の仕組みについて調査した結果をもとに解説していきたいと思います。 AttackPathポリシーとは？ AttackPathポリシーは、セキュリティリスクの高い経路を特定し、対策を講じるためのポリシーです。 AttackPathポリシーはデフォルトで有効になっており、さまざまなセキュリティリスクを評価して相関関係を見つけ出します。 セキュリティリスクを評価して相関関係を見つけ出します、と言われてもピンと来ないと思いますので、例を挙げて説明したいと思いますが、たとえば以下のようなインスタンスA・Bがあったとします。 ・インスタンスA：脆弱性を抱えている ・インスタンスB：脆弱性を抱えている、 かつ、パブリック公開されている この場合、脆弱性を抱えているのはインスタンスA・Bどちらも同じですが、パブリック公開されているインスタンスBの方がAと比較してセキュリティリスクが高い、というような考え方ができるかと思います。 このように、複数の条件（セキュリティリスク）に当てはまるものは攻撃や侵害を受ける可能性が高いとしてアラート検知するのがAttackPathポリシーとなります。 なぜAttackPathポリシーが重要なのか？ AttackPathポリシーは、セキュリティ侵害の可能性を高める要因を特定する意味で非常に重要になります。 要因には、過度に寛容なIDや権限、ネットワークへの露出、インフラストラクチャの設定ミス、アプリケーションの脆弱性などが含まれます。これらの要因が組み合わさることで、リスクがより高まることになります。 AttackPathポリシーは、こうしたリスク要因を視覚化し、すぐに対応が必要なものを特定するのに役立ちます。 特に、インターネットに公開されている仮想マシンやアプリケーションが、外部からの攻撃に対してどれだけ脆弱であるかを把握するのに役立ちます。 たとえば、脆弱性を抱えるリソースが大量にあったとして（それはそれで問題がありますが）、AttackPathポリシーで検知されたアラートを確認することで、よりリスクが高いリソースから優先的に対処していくといった対応が可能になります。 AttackPathポリシーのほとんどはPrismaCloudが定めているポリシー重要度がCritical（一番重要度が高い）となっていることからも、その重要性が伺えるかと思います。 アラートが大量に発生して対応が追い付いていない状態になってしまっているような場合でも、AttackPathポリシーで検知したアラートは最優先で確認・対処すべきというような位置づけだと考えられます。 AttackPathポリシーでの検知の仕組み AttackPathポリシーで監視を行うためには、まずポリシーが有効化されている必要があります。 基本的にはデフォルトで有効になっていますが、PrismaCloudコンソールで[ガバナンス]を選択し、ポリシータイプを「AttackPath（攻撃経路）」でフィルタリングして、AttackPathポリシーが有効になっていることを確認できます。 また、各AttackPathポリシーは、それぞれ複数のルールがあり、すべてのルールに一致するものが見つかるとアラートを生成する動きになります。 イメージが付きづらいと思うので、「Data breach risk due to an Azure Cosmos DB that is reachable from untrusted Internet sources having key based authentication enabled」というAttackPathポリシーで検知した場合を例に挙げて説明したいと思います。 ・検知したアラートのポリシー名の左横にあるマークをクリックします ・左ペインで「ルールの表示」を選択すると、このAttackPathポリシーで検知する条件となるルールが表示されます。 以下の場合、 ①Azure Cosmos DB (PaaS) instance reachable from untrust internet source ②Azure Cosmos DB key based authentication is enabled という別のポリシーがあり、その両方でアラート検知されていることがこのAttackPathポリシーで検知するためのルールになります。 ・試しに①②のポリシーでアラート検知しているか確認したところ、AttackPathポリシーでアラート検知されていた「cosmosdb-test-account」というリソースに対して、①②両方のポリシーでアラート検知されていることが確認できました 上記の通り、AttackPathポリシーには、複数のポリシーでアラート検知していることを条件（ルール）としているものが存在します。 その場合には、ルールとなっているポリシーすべてについても有効化されている必要があることに注意しましょう。 AttackPathポリシーの注意点 「AttackPathポリシーでの検知の仕組み」でも触れた通り、AttackPathポリシーは様々なセキュリティ侵害の可能性を高める要因の組み合わせでアラート検知します。 要因の中には、CSPM機能だけ利用している場合には監視できないものも含まれています。 たとえば、CWPP（Prisma CloudのCompute機能）で検知される項目がルールの一つになっている場合や、CIEM（Prisma CloudのIAMセキュリティ機能）で検知される項目がルールの一つになっている場合は、その機能が利用できる状態になっていないとアラート検知しませんので、その点は注意が必要です。 まとめ 調べてみた結果、AttackPathポリシーがセキュリティリスクを特定し、対策を講じるのに役立つ重要なポリシーであることが分かりました。次回も、Prisma Cloudについて情報をお届けできればと思います。 また、当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp ご興味のある方は是非、お気軽にお問い合わせください。
管理者
