本記事は執筆時点（2025年5月）の情報です。最新の情報は製品ドキュメントを参考にしてください   概要 ワークスペース上でレコードを開いた際、「Compose email」というアクションが用意されています。 こちらをクリックするとOutlookと同じ操作感で、ワークスペース上でもメールを作成することができます。 起票されたインシデントやケースなどのチケットに対し、起票者とメールでやり取りをすることができる便利な機能ですが、すべてのテーブルに「Compose email」がデフォルトで表示されているわけではないことに気が付きました。 そのため、今回の記事では「Compose email」を表示させる設定方法について調べました。   設定方法 「Compose email」がデフォルトで表示されていない、ケースタスク [sn_customerservice_task]を例に手順を記載します。   ケースタスクテーブルに移動し、任意のレコードを開きます。 そして、フォームコンテキストメニューを開き、Configure > Dictionaryを選択します。 Dictionary Entryテーブルに遷移したら、Typeが「Collection」となっているレコードを開きます。 「Advanced view」をクリックします。 Attributesフィールドに「email_client=true」と入力し保存します。 設定は以上となります。 ワークスペースを確認すると「Compose email」が表示されるようになりました。   ワークスペースから送信したメールは、送信元のレコードと紐づく形でメールが作成されます。 そのため、関連リストを設定することで、インシデントやケースなど一つ一つのチケット単位で紐づくメールの送信履歴を表示させることが可能になります。   さいごに ワークスペースからメールを送信するための設定手順を記事にしました。 エンドユーザーから起票されたチケットに対してメールでの確認が必要となった場合、Outlookを開かなくてもメールを送信できる、かつ送信元のチケットと紐づいて管理が楽になる非常に便利な機能だと思いました。   以下、弊社HPも是非ご参照ください。 ServiceNow ServiceNowは、企業の生産性向上や業務プロセス改善を支えるサービスマネジメントクラウドソリューションです。従業員満足度・顧客満足度の向上、業務効率化を強力に支援します。 www.scsk.jp

はじめに Prisma Cloudには多くのREST APIが用意されており、これを活用することで、運用の効率化やセキュリティの強化が可能になります。 例えば、手作業で行っていた作業の自動化や、独自のレポートを作成、Prisma Cloud外のデータとの連携など、独自の運用に合わせたツールを作成することができます。 しかしながら、REST APIも機能更新されたり、非推奨となったりと定期的に作ったツールに問題がないかを確認する必要があります。 この更新の確認を実施せず、作りっぱなしとなっているツールも多いのではないでしょうか。 非推奨となったREST APIは将来削除される可能性があるため、計画的に代替用REST APIに移行することが推奨です。 今回はPrisma Cloud Release Noteにて、2025年1月から5月に発表されたアップデート情報から、更新されたREST APIや、非推奨となったREST APIをご紹介します。 非推奨となったREST APIを利用している場合は、代替用REST APIの利用を検討いただく必要があります。 詳細は以下からご確認ください(英文) ・ Features Introduced in 2025 2025年1月 1月は非推奨に変更されたREST APIはありませんでした。 更新されたREST APIは以下の通りです。 更新されたREST API 更新された内容 Alerts API 以下エンドポイントがAlerts APIに追加されました Get Policy Remediation   2025年2月 2月に非推奨になったREST APIは以下です 非推奨に変更されたAPI 代替用REST API Get Vulnerability Overview V1 –  GET /uve/api/v1/dashboard/vulnerabilities/overview Get Vulnerability Overview V2 –  GET /uve/api/v2/dashboard/vulnerabilities/overview Get Vulnerability Overview V3 –  GET /uve/api/v3/dashboard/vulnerabilities/overview Get Vulnerability Overview – POST Get Vulnerability Overview – POST | Develop with Palo Alto Networks Get Prioritized Vulnerabilities V1 –  GET – /uve/api/v1/dashboard/vulnerabilities/prioritised Get Prioritized Vulnerabilities V2 –  GET – /uve/api/v2/dashboard/vulnerabilities/prioritised Get Prioritized Vulnerabilities V3 –  GET – /uve/api/v3/dashboard/vulnerabilities/prioritised Get Prioritized Vulnerabilities V4 –  GET – /uve/api/v4/dashboard/vulnerabilities/prioritised Get Prioritized Vulnerabilities POST –  POST /uve/api/v5/dashboard/vulnerabilities/prioritised Get Top Impacting Vulnerabilities –  GET /uve/api/v1/dashboard/vulnerabilities/prioritised-vuln Get Top Impacting Vulnerabilities V2 –  GET /uve/api/v2/dashboard/vulnerabilities/prioritised-vuln Get Top Impacting Vulnerabilities POST –  POST /uve/api/v3/dashboard/vulnerabilities/prioritised-vuln Get CVE Overview –  GET /uve/api/v1/dashboard/vulnerabilities/cve-overview Get CVE Overview V2 –  GET /uve/api/v1/cve-overview Get CVE Overview POST –  POST /uve/api/v2/cve-overview 更新されたREST APIは以下の通りです。 更新されたREST API 詳細 Satellite APIs リクエストbodyが更新されました。 POST /appid/api/v1/satellite のリクエストは clusterAssetId オブジェクトのみを必須とするようになりました。   2025年3月 非推奨に変更されたREST APIはありませんでした。 更新されたREST APIは以下の通りです。 更新されたREST API 詳細 Perform Event Search API POST /search/event のリクエストボディが更新され、ソートフィールドの値が大文字から小文字に変更されました。 Get Registry Scan Results Download Registry Scan Results Get Registry Image Names Prisma にオンボードされたアカウントにのみ適用される新しいクエリパラメーターが、「 Get Registry Scan Results 」「 Download Registry Scan Results 」「 Get Registry Image Names 」API に導入されました。このパラメーターを使用すると、CaaS（コンテナ・アズ・ア・サービス）仕様（AWS Fargate、GCP Cloud Run、ACI）の一部としてデプロイされたレジストリイメージをフィルタリングできます。 パラメーターの名前は hasCAASSpecReferences  です。 Support Images Field Prisma にオンボードされたアカウントにのみ適用される新しいクエリパラメーターが、「 Get Discovered Cloud Entities API 」に追加されました。このパラメーターを使用すると、CaaS（コンテナ・アズ・ア・サービス）仕様（AWS Fargate タスク定義、GCP Cloud Run、ACI）で定義されたコンテナイメージ名によって、クラウドで検出されたエンティティをフィルタリングできます。 Support Service Field Prisma にオンボードされたアカウントにのみ適用される新しいパラメーターが、「 Get Discovered Cloud Entities API 」のレスポンスに追加されました。このパラメーターは、検出された GCP Cloud Run サービス名を指定するためのものです。 パラメーターの名前は service  です。 Support CaaS Specification References Total Field Prisma にオンボードされたアカウントにのみ適用される新しいパラメーターが、以下の API に導入されました Get Host Scan Results Get Image Scan Results Get Impacted Container Compliance Policy Get Impacted VMs Compliance Policy Host App Firewall Policy Impacted Get Impacted Host Vulnerability Policy Get Impacted Image Vulnerability Policy Get Registry Scan Results Get VM Image Scan Results このパラメーターは、CaaS(Containers as a Service)仕様（AWS Fargate タスク定義、GCP Cloud Run、ACI）に関連付けられた参照数を指定するためのものです。 パラメーターの名前は caasSpecReferencesTotal  です。 Support for a Amazon Fargate Task Definition Prisma にオンボードされたアカウントにのみ適用される新しい列挙（Enum）値がスキーマに追加され、Amazon Fargate タスク定義の新しいスキャン結果タイプを指定できるようになりました。 パラメーターの名前は aws-fargate-task-definitionshared.ScanResultType  です。   2025年4月 REST APIの更新と非推奨になったREST APIはありませんでした。 2025年5月 非推奨になったREST APIは以下となります。 今回はSecure the Runtimeだけになっています。 REST APIバージョンは34.01.126となっています。 非推奨に変更されたREST API名 代替REST API Deprecation of the CNNS feature Cloud Native Network Segmentation（CNNS） 機能は、コンテナおよびホストに対するネットワーク脅威からの保護を強制する目的では非推奨となりました。 ただし、他のネットワーク監視モードが利用できないシナリオにおいては、レーダーによる可視化などの 監視目的 に限り使用することができます。 現在の推奨事項としては、CNNS ベースのネットワーク監視もすべて無効化することです。 REST APIの更新は以下の通りです。 今回はSecure the Runtimeだけになっています。 REST APIバージョンは34.01.126となっています。 更新されたREST API 詳細 Download Image Scan Results API (Prisma Cloud Workload Protection) 「Download Image Scan Results API」のCSVファイルのレスポンスに、新しい列が追加されました。 この新しいフィールドは、Prisma Cloud と Cortex XDR の統合において統合された XDR エージェントの数を一覧表示します。 この列の名前は  Cloud Security Agent Hosts  です。 Support for new agentless APIs (Prisma Cloud Workload Protection) 以下の新しい API エンドポイントにより、エージェントレスアカウントに対してスキャナーの最大数を設定したり、エージェントレススキャンの統計情報を取得したりすることができます。 Agentless Max Scanners Agentless Scan Statistics Support for a new enum value (Prisma Cloud Workload Protection) スキーマに新しい列挙（Enum）値が追加され、 gcp-cloud-run-serviceshared.ScanResultType  を指定できるようになりました。 さいごに 今回はPrisma Cloud release noteの更新されたREST APIと非推奨REST APIを紹介しました。 定期的にリリースノートを確認し、非推奨REST APIを使用しないようにしましょう。 当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 ご興味のある方は是非、お気軽にお問い合わせください。

どうも、SCSKの谷です。 私の部署では監視サービスを提供しているのですが、実際に監視しているメトリックデータの数値を見たいというお客様が一定数います。 そのようなお客様に対してMackerelを利用した監視サービスを提供する場合、Mackerelではグラフを参照することはできますが、 実際に監視で得られた数値を参照することはできないので、お客様の要望に応えられません。 そこで、MackerelはAPIを公開しているので、APIを利用して監視対象のメトリックの数値データを取得してこれるのではと考え、実装してみることにしました。   部署の後輩である嶋谷君が書いた最近の記事について以下にまとめてますので、ご覧になっていない方は是非ご覧ください！ ■投稿記事 ・ Mackerel でマイクロサービスを監視してみた – TechHarmony ・ CloudWatchのアラート通知をMackerelに移行してみた – TechHarmony   性能データCSVダウンロードスクリプト 概要 今回は、PowerShellを用いて性能データをCSVでダウンロードするスクリプトを作成しました。 大まかに以下の2手順で性能データをCSVでダウンロードしていきます。 1.　APIを用いて、Mackerel上の監視対象ホストの指定したメトリクスの時系列データを取得し、JSON形式で保存 2.　取得したJSONデータをCSV形式に変換 機能要件 ・CSV形式で性能データを出力できること ・APIで取得する性能データの取得期間を指定できること ・指定したメトリクスのデータを取得できること 実行環境 今回の実行環境はWindows11です。 （PowerShellの実行環境とインターネットへの接続環境があれば、利用できる想定です) スクリプト詳細 作成したスクリプトは以下の構成からなります。 getcsv.ps1 親スクリプト 必要情報の入力と子スクリプトの呼び出し getjson.ps1 子スクリプト APIを用いて対象ホストのデータを取得しJSON形式で保存 writejsontocsv.ps1 子スクリプト JSON形式のファイルをCSV形式に変換し保存   getcsv.ps1（必要情報の入力と子スクリプトの呼び出し） 以下、getcsv.ps1のスクリプトとなります。 #getcsv.ps1 param(     [string]$dateTime,     [string]$apiKey,     [string]$hostId,     [string]$metricName,     [string]$startDateTime,     [string]$endDateTime,     [string]$jsonFilePath,     [string]$csvFilePath ) #現在日時取得 $dateTime = (Get-Date).ToString("yyyyMMddHHmmss") #出力先設定 $jsonFilePath = "jsonの出力先パス\response.json" $csvFilePath = "csvの出力先パス\output_$dateTime.csv" #各パラメータ入力 $apiKey = Read-Host "APIキーを入力してください" $hostId = Read-Host "ホストIDを入力してください" $metricName = Read-Host "取得するメトリクス名を入力してください" $startDateTime = Read-Host "開始日時を入力してください(yyyymmdd hhmmss)" $endDateTime = Read-Host "終了日時を入力してください(yyyymmdd hhmmss)" #JSONデータ取得バッチ実行 .\getjson.ps1 -apiKey $apiKey -hostId $hostId -metricName $metricName -startDateTime $startDateTime -endDateTime $endDateTime Write-Output "取得したJSONデータをCSVに変換します" #CSV変換バッチ実行 .\writejsontocsv.ps1 -jsonFilePath $jsonFilePath -csvFilePath $csvFilePath (1) 必要パラメータの入力 パラメータの詳細につきましては、スクリプトの実行手順で説明しています。 (2) JSONデータ取得バッチ実行 getjson.ps1に必要なパラメータを渡して、実行します。 (3) CSV変換バッチ実行 writejsontocsv.ps1に必要なパラメータを渡して、実行します。     getjson.ps1（APIを用いて対象ホストのデータを取得しJSON形式で保存する処理） 以下、getjson.ps1のスクリプトとなります。 #getjson.ps1 param ( [string]$apiKey, [string]$hostId, [string]$metricName, [string]$startDateTime, [string]$endDateTime )       # UNIXタイムスタンプに変換 $wkstartDateTime=[DateTime]::ParseExact($startDateTime, "yyyyMMdd HHmmss", $null).ToUniversalTime() $fromUnixTime = [int][double]::Parse($wkstartDateTime.Subtract([datetime]'1970-01-01').TotalSeconds) $wkendDateTime=[DateTime]::ParseExact($endDateTime, "yyyyMMdd HHmmss", $null).ToUniversalTime() $toUnixTime = [int][double]::Parse($wkendDateTime.Subtract([datetime]'1970-01-01').TotalSeconds) # APIリクエストURLの作成 $apiUrl = "https://api.mackerelio.com/api/v0/hosts/$hostId/metrics?name=$metricName&from=$fromUnixTime&to=$toUnixTime" # APIリクエストの実行 $response = Invoke-RestMethod -Uri $apiUrl -Headers @{ "X-Api-Key" = $apiKey } -Method Get # JSONデータをテキストファイルに保存 $response | ConvertTo-Json | Out-File -FilePath "response.json" Write-Output "APIリクエストが完了し、データがresponse.jsonに保存されました。" (1) 入力した日時をUNIXタイムスタンプに変換 APIリクエストURLではUNIXタイムスタンプである必要があるため、最初に「yyyyMMdd HHmmss」で指定した開始日時と終了日時を UNIXタイムスタンプに変換しています。 (2) APIリクエストURLの作成 入力した値を組み合わせて、ホストのメトリックの値取得用のAPIリクエストURLを作成します。 メトリクス名及び取得開始日時、取得終了日時はクエリパラメータで指定してます。 ・name = メトリック名 ・from  = 取得開始日時 ・to      = 取得終了日時 APIリクエストURLについては、以下のMackerel公式ドキュメントを参考にしています。 Mackerel API ドキュメント（v0） – Mackerel API ドキュメント (v0) (3) APIリクエストの実行 作成したAPIリクエストURLを実行し、メトリックのデータを取得します。 Invoke-RestMethodを使用してAPIリクエストを実行しています。 (4) 取得したデータをJSON形式で保存 取得したデータを ConvertTo-JsonでJSON形式で保存します。 ファイルの保存先として、実行しているフォルダ上にそのまま保存してます。     writejsontocsv.ps1（JSON形式のファイルをCSV形式に変換し保存） 以下、writejsontocsv.ps1のスクリプトとなります。 #writejsontocsv.ps1 param( [string]$jsonFilePath, [string]$csvFilePath )         # JSONファイルを読み込み $jsonContent = Get-Content -Path $jsonFilePath -Raw | ConvertFrom-Json # 出力用のCSVデータを格納するための配列を初期化 $csvData = @() # 各メトリクスを処理 foreach ($metric in $jsonContent.metrics) { # UNIXタイムをJSTの "YYYYMMDD HHMMSS" 形式に変換 $timeJST = [System.TimeZoneInfo]::ConvertTimeBySystemTimeZoneId( [System.DateTimeOffset]::FromUnixTimeSeconds($metric.time), "Tokyo Standard Time" ).ToString("yyyy/MM/dd HH:mm:ss") # CSVの行を作成 $csvData += [PSCustomObject]@{ Time = $timeJST Value = $metric.value } } # CSVファイルとして出力 $csvData | Export-Csv -Path $csvFilePath -NoTypeInformation -Delimiter ',' Write-Host "JSONファイルからCSVファイルへの変換が完了しました。出力ファイル: $csvFilePath" (1) JSONファイルの読込 getjson.ps1で出力したメトリックデータのJSONファイルを読み込みます。 (2) 各メトリクスの処理 JSONファイル内のパラメータは「Time（日時）」と「Value（メトリックの値）」となっているので、 上記を1ペアとして配列に繰り返し格納していきます。 (3) CSVファイルの出力 配列内に格納したデータをExport-Csvを用いてCSVファイルとして出力します。 使用方法 作成した性能データ出力スクリプトの使用方法を説明していきます。     事前準備 Powershellのバッチ実行設定で実行可になっていない場合、以下作業を実施してバッチ実行可に変更する必要があります。 (1) Windows PowerShellを管理者として実行する (2)「Get-ExecutionPolicy」と入力し、「Restricted」の場合は以下を実行(「RemoteSigned」の場合は実行不要です。) Set-ExecutionPolicy -ExecutionPolicy RemoteSigned 実行ポリシーの変更に「Y」     対象ホストのメトリック名の確認 コマンドプロンプトで取得対象のメトリック名を確認します。 (1) コマンドプロンプトを開く (2) 以下のコマンドを入力する curl -k -X GET -H “X-Api-Key:【APIキー】” “https://api.mackerelio.com/api/v0/hosts/【ホストID】/metric-names” (3)出力したいデータのメトリック名を確認する   スクリプト実行 スクリプトを実行して、性能データをCSV形式で出力します。 (1) 以下のスクリプトファイルを任意の場所に設置する ・getcsv.ps1 ・getjson.ps1 ・writejsontocsv.ps1 (2) PowerShellを開く (3) スクリプトの設置場所にカレントディレクトリを移動する (4) getcsv.ps1を実行する (5) 必要なパラメータを入力する データの取得のために必要なパラメータを入力していきます。 パラメータについては以下の通りです。 変数名 パラメータ 概要 apiKey APIキー MackerelへAPIリクエストするために必要なAPIキー hostId ホストID Mackerel上に登録されているホストを識別するための一意のID、取得したいホストのIDを指定 metricName メトリック名 Mackerelで監視しているホストのメトリックの中で取得したいメトリック名を指定 startDateTime 取得開始日時 メトリックデータを取得したい期間の開始日時 endDateTime 取得終了日時 メトリックデータを取得したい期間の終了日時 APIキーについては、以下から確認できます。 オーガニゼーション詳細ページ > APIキータブ > APIキー 　  ホストIDについては、以下から確認できます。 (6) パラメータ入力後、処理が実行されCSVファイルが出力されたこと確認する   指定した取得期間によりデータの時間幅（ピッチ）が変わる Mackerel側の仕様で、指定した取得期間の長さによって、APIで取得したデータの時間幅が変わりますのでご注意ください。 参考として、以下に取得期間による時間幅をまとめております。 取得期間 時間幅（ピッチ） 例 1時間単位 1分 2025/5/1 15:00 ~ 2025/5/1 18:00 1日単位 5分 2025/5/1 15:00 ~ 2025/5/4 15:00 1週間単位 10分 2025/5/1 15:00 ~ 2025/5/14 15:00 1月単位 1時間 2025/5/1 15:00 ~ 2025/7/15 15:00   性能データCSVダウンロード結果 本スクリプトを用いて、以下のメトリックのデータを取得してみました。 取得データ メトリック名 備考 CPU使用率 cpu.steal.percentage   メモリ使用率 memory.used、memory.total (memory.used/memory.total)*100で算出 ディスク使用量 filesystem.xvda1.used   取得対象のホストは以下の通りです。 AWS EC2 ・CPU　t2.micro ・RAM　0.93 GiB ・OS　　Linux/UNIX ・ストレージ　8GiB 取得期間は「2025年5月21日 7時19分」から「2025年5月21日 13時19分」の6時間となります。 CPU使用率 CSVデータをもとにEXCELで作成したグラフです。 Mackerelの管理画面でのグラフです。 メモリ使用率 CSVデータをもとにEXCELで作成したグラフです。 メモリ使用率につきましては、直接APIで取得できないので、メモリ使用量とメモリサイズのメトリックデータを取得し、計算しています。 Mackerelの管理画面でのグラフです。 Mackerelにはメモリ使用率のメトリックがないため、メモリ使用量のグラフとなっております。 ディスク使用量 CSVデータをもとにEXCELで作成したグラフです。 ディスク使用量とディスクサイズのメトリックデータを組み合わせています。 Mackerelの管理画面でのグラフです。 同様に、ディスク使用量とディスクサイズのグラフとなっております。   スクリプト所感 今回でスクリプトを作成したことによりメトリックデータをCSV形式ダウンロードできるようになったので、データを成形したり複数のデータを組み合わせることができるようになりました。また、Mackerel上のグラフでは、時間ごとの細かいメトリックの数値を把握することが難しかったので、可視化しやすくなったと感じました。スクリプト自体も単純な対話形式のものにしたので、誰でも利用できるようにできたかなと思います。 実際に使ってみて、コマンドでメトリック名一覧を出力後に、出力したいメトリックデータのメトリック名を探し出すのは大変だと感じました。また、毎回APIキーやメトリック名を入力しなけらばならないので、そこは結構手間だと感じました。 CSV形式でダウンロードできるようにすることが今回の大きな目標だったのでひとまず達成することができました。 しかし、利便性の面ではまだまだ改善の余地があると感じています。 ■改善点の例 ・ファイル出力先を指定できない ・複数のメトリックデータを一度に取得できない ・複数ホストメトリックデータを一度に取得できない など   補足） MoniPro Mに実装しました 実は、今回のスクリプトをもとに開発担当の方に内容を改善いただき、弊社のサービスであるMoniPro Mでも監視データをcsvダウンロードできるようにしていただきました。 MoniPro Mにつきましては、下記の公式サイトを参照ください。 MoniPro M｜SCSK株式会社 性能データCSVダウンロード機能 性能データCSVダウンロード機能はSCSK の統合監視プラットフォーム「FusionCORE」のうちのお客様向けポータルである HEARTIL Contact Portal(HCP)内の機能になります。 取得したいホストとメトリックを選択し、ダウンロードボタンを選択することで性能データをCSV形式でダウンロード可能です。 選択したそれぞれのCSVファイルがアーカイブされZipファイル形式でダウンロードされます。 メトリックについては取得可能なメトリックのみ選択できるようになっています。 ■特徴 ・Mackerelの管理単位である、サービス、ロールで対象ホスト絞りこむことが可能 （ 「サービス」「ロール」とは – Mackerel ヘルプ ） ・取得開始時間と取得終了時間を指定可能 ・複数のホストとメトリックの性能データCSVを同時にダウンロードが可能 ・Zipファイル形式にアーカイブされた状態でダウンロード 所感 今回の機能追加にあたり、サービスの機能として利用できるよう開発担当の方に本スクリプトを修正・改善をしてもらってHCPに実装していただきました。 HCPへの実装後に実際に利用してみて、自身が作成したときのスクリプトよりも非常に利用しやすくなっており感動しました。 以下に利用しやすくなったと感じた点をまとめております。 ・ダウンロードしたいメトリックのチェックボックスを選択するという直感的な操作で簡単に性能データCSVをダウンロード可能 ・ホスト名の左側にあるチェックボックスを選択することで選択可能なメトリックをまとめて選択できる ・検索条件でサービスやロールから対象ホストを絞りこむことができるので、Mackerel上のホストが多くても対象ホストの性能データを 簡単にダウンロード可能 ・複数ホストと複数メトリックをまとめてダウンロードできるので、一つずつダウンロードする手間がかからず便利 まとめ 今回はMackerel上で監視しているホストの性能データをCSV形式でダウンロードするスクリプトを作成してみました！ 先ほども述べましたが、ひとまずCSV形式でダウンロードできればよいと考えており、スクリプトについて細かいところまで作りこんでおらず使用しづらい箇所があったのですが、CSV形式でダウンロードするという目的は達成することができました。 併せて、MoniPro Mに実装した性能データCSVダウンロード機能について紹介させていただきました。 自身が作成したスクリプトをベースに実際に機能として追加していただけたので、感慨深いものがあります。 もし本記事の内容にご関心をお持ちいただけましたら、ぜひ一度サービスをご体験いただければ幸いです。

こんにちは。SCSKの安藤です。 今年も昨年に引き続き、「 Interop Tokyo 2025 」にZabbix社と共同出展します。 ブース番号は 6F04 です。   開催概要 【主催】 Interop Tokyo 実行委員会 【概要】 ６月１１日（水）　１０時～１８時 ６月１２日（木）　１０時～１８時 ６月１３日（金）　１０時～１７時 　　※来場には 事前登録(無料) が必要です。 【会場】 　　 幕張メッセ 　国際展示場ホール４～８   Zabbixブース場所 Zabbixブース（ブース番号：6F04） は、 Hall6出入口 そばです。   SCSKの出展内容 SCSKは、Zabbixプレミアムパートナー として、 弊社のZabbix関連ソリューションの展示 をします。 手軽に環境を構築できる、Quick Start Packageや、バージョンアップ事例のご紹介もあります。 オープンソースの監視ツールであるZabbixに興味のある方は、ぜひご来場ください！   同ブース内で ショートセミナー も開催します。 タイトル：Zabbix Cloud 登場！Zabbixのプロが実際に使ってみた 登壇日時：①６月１１日（水）　１２時４０分～１２時５５分 　　　　　②６月１２日（木）　１６時２５分～１６時４０分 　　　　　③６月１３日（金）　１０時３５分～１０時５０分 各日１回、３回ともセッションの内容は同じですので、ご都合のつく回にぜひお越しください。   当日はZabbixブースへのご来場を心よりお待ちしております！   Interopとは Interop Tokyoは、延べ12万人が来場する国内最大級のインターネットテクノロジーのイベントです。 毎年国内外から数百の企業・団体が参加し、技術動向とビジネス活用のトレンドをいち早く体感できる場です。   ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★   SCSK Zabbixチャンネル 本チャンネルでは、SCSK株式会社でのZabbixに関するトレンド/事例紹介などを動画にまとめて取り上げております。最新のトピックについては、以下の弊社HPもしくはツイッターアカウントをぜひ参照ください。ツイッターアカウント： www.youtube.com ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★   x.com   x.com

こんにちは、Catoクラウド エンジニアの中川です。 突然ですが、Catoクラウドを利用するにあたって、Socketの選び方に迷っていませんか？   「X1500・X1600・X1700のどれを選べばいいの？」 「拠点の規模に合ったSocketがわからない…」   そんなお悩みをお持ちの方に向けて、この記事では Cato Socketの物理デバイス3モデル（X1500 / X1600 / X1700）について、以下のポイントを中心にわかりやすく解説します。 各モデルのスペックと性能の違い 適した導入シーンと選定の目安 本記事を通じて、 自社に最適なSocketモデルを選ぶため のご参考になれば幸いです。 Socketとは？ まず前提として、 Socket（ソケット）とは、Catoクラウドに接続するためのエッジデバイス のことです。 インターネット回線に接続するだけで、特別な設定を必要とせず、 ゼロタッチ でCatoクラウドと接続されます。Socketを利用すれば、ルータやFirewallに設定が必要なIPsec接続構成のような手間がかかりません。 Socketには、物理的なハードウェアデバイスと仮想アプライアンス（vSocket）の2種類がありますが、この記事では、 物理デバイスである「X1500」「X1600」「X1700」の3モデルに焦点を当て、それぞれのスペックや機能、適した利用シーン を比較してご紹介します。 データセンターや本社・支社など、拠点にSocketを導入する際に、どのモデルを選べばよいか迷っている方の参考になれば幸いです！ Socket X1500 / X1600 / X1700 の比較 Cato Socketには、拠点の規模や用途に応じて選べる複数のモデルが用意されています。 ここでは、 X1500、X1600、X1700 の3モデルについて、 仕様 を比較しながらご紹介します。 機種別スペック比較表 項目 X1500 X1600 ※1 X1700 写真 Basicモデル LTEモデル 特徴 ベーシックモデル 高性能・多様なポート ハイエンドモデル 最大スループット ※2 500 Mbps 1 Gbps X1700 – 3Gbps X1700B – 10Gbps  サイズ X1500 – 奥行き:105.5mmx 幅:165mm x 高さ:43mm X1500B – 奥行き:130mmx 幅:180mm x 高さ:30mm 非常にコンパクトで、よく私たちはお弁当箱サイズと表現します 奥行き: 256mm x 幅:200mm x 高さ: 44mm およそX1500の約2倍のサイズ感です X1700 – 奥行き:448mm x幅:435mm x 高さ:44mm X1700B – 奥行き:553mm x幅:438mm x 高さ:44mm ラックマウント専用です 重量 約700g 約1kg 約2.5kg インターフェース RJ45ポート x4 1G COMBOポート(RJ45とSFP)x2 10G SFP+ポートx2 2.5GのRJ45ポート x4 標準 – RJ45ポート x8 オプションで以下を追加可能             4 x 1GbE 2 x 1Gb Fiber 2 x 10Gb Fiber 4 x 10Gb Fiber 電源 12V電源アダプタ 12V電源アダプタ（ロック機構付き） 冗長電源ユニット　2 x 300W 設置方法 卓上・ラックマウント ラックマウント・壁掛け対応 ラックマウント専用 ※1 X1600の詳細は、 徹底解説！Cato Socket X1600 – TechHarmony の記事も合わせてご参考ください。 ※2 最大スループットは、SocketとCatoクラウド PoP間での上り下りの合計値です。 あくまで目安の数値であり、上り下りが両方ともMAXに出続けるという状況はほぼないため、上記の目安帯域以上でも利用可能な場合が多いです 。 各モデルの選び方 X1500：中規模拠点まで対応。ベーシックモデル コンパクトで設置しやすい、ベーシックモデルです。 最大スループット500Mまで対応しているので、従業員の多い大規模拠点などでなければ、まずはX1500を選定いただければと思います。 X1600,X1700とモデルが上がるにつれて当然価格も上がります。コストを抑えたい場合にもおすすめです。 X1600：中〜大規模オフィス向けの高機能モデル 10G SFP+や2.5G RJ45などのインターフェース、LTEモデルの利用要件がある場合に選定いただければと思います。 X1500よりもポート数が豊富なため、Socketを拠点内のルータ・L3SWの代わりとして利用することができるかもしれません。 今後は、Wi-Fiモデル、LTE+Wi-Fiモデルの展開が予定されています。 X1700：データセンター向けのハイエンドモデル 最大3Gbps、X1700Bであれば10Gbpsのスループットに対応可能なハイエンドモデルです。 従業員の多い本社などの大規模拠点や、トラフィックの集まるデータセンターなどの拠点で多く選ばれています。 各Socketの大きな違いは 最大スループット です。 拠点の規模 を考慮して、最適なSocketを選ぶことが重要です。 まとめ Cato Socketは、拠点の規模やネットワーク要件に応じて柔軟に選べるエッジデバイスです。 本記事では、 X1500・X1600・X1700 の3モデルについて比較してきました。 それぞれのSocketには特徴があり、 「どの拠点に、どのモデルを導入すべきか」 を判断するための材料として、本記事が参考になれば幸いです。 また、想定よりも帯域が必要となった際などには、Socketのアップグレードも可能ですのでご安心ください。 もしご判断に迷うようでしたら、SCSKへご相談いただければ、既存のトラフィック状況などから適したSocketの選定させていただくことが可能です。 ぜひお問い合わせいただければと思います。 参考資料 本記事は以下の、Cato Socketに関する公式情報を参考に記載しています。 Cato Socket Deployment Guides and Data Sheets – Cato Learning Center

現在のデジタルトランスフォーメーション（DX）の進展に伴い、クラウドにおけるデータ保護と法令遵守はますます重要になっています。特に、クラウドリソースの監視やリスク管理を強化するために、クラウドセキュリティ体制管理（CSPM）ツールが有効な手段となります。CSPMツールは、クラウドの設定ミスやセキュリティギャップを検出し、企業の安全性を高めるために不可欠な役割を果たします。 企業が安心してクラウド技術を活用するためには、データ保護と法令遵守を確実にすることが欠かせません。企業によっては、特定のコンプライアンス基準に準拠することが求められる場合があります。例えば、業界ごとの規制や法令遵守のために、ISO 27001やPCI DSSといった厳格な基準への対応が必要となることもあります。そこで、CSPMツールは、こうした複数のコンプライアンス基準に対応するように設計されており、クラウド環境の安全性を確保するための重要なソリューションとなります。 そこで本記事では、Prisma Cloudが対応しているコンプライアンス基準について一部ご紹介します。   Prisma Cloud が対応しているコンプライアンス基準 Prisma Cloudは、クラウド環境のセキュリティを強化するためにCISやCSA CCM、GDPRなど数多くのコンプライアンス基準をサポートしています。最新の対応コンプライアンスの一覧は下記リンクを確認してください。 コンプライアンス基準 AWS APRA CPS 234, Brazilian Data Protection Law (LGPD), CIS AWS 3 Tier Arch v1.0, CCPA 2018, CIS v1.2, CIS v1.3, CIS AWS v.1.4, CSA CCM v3.0.1, CSA CCM v4.0.1, CMMC, GDPR等 Azure Azure Security Benchmark (ASB) v2, Azure Security Benchmark (ASB) v3, APRA CPS 234, Brazilian Data Protection Law (LGPD), CCPA 2018, CIS v1.1, CIS v1.2, CIS v1.3, CIS v1.3.1等 GCP APRA CPS 234, Brazilian Data Protection Law (LGPD), CCPA 2018, CIS v1.0, CIS v.1.1, CIS v.1.2, CIS GKE v1.1, CSA CCM v3.0.1, CSA CCM v4.0.1, CMMC, GDPR, HITRUST v9.3等   コンプライアンスをPickupして紹介 このように、Prisma Cloudは数多くのコンプライアンス基準をサポートしています。 ここでは、Prisma Cloudが対応するコンプライアンス基準の中から、特によく聞かれる「ISO 27001:2022」「CIS AWS v4」「PCI DSS v4.0」について紹介します。   ISO 27001:2022 ISO 27001:2022とは、情報セキュリティ、サイバーセキュリティ、プライバシー保護に関する国際規格であり、2022年2月にISOから発行されました。 この規格は、ISO/IEC 27000シリーズの一部であり、情報セキュリティやサイバーセキュリティ等のリスクに対する管理策とその導入方法を詳しくまとめています。原文のタイトルは「Information security, cybersecurity and privacy protection – Information security controls」です。   CIS AWS v.1.4 CIS AWS v.1.4は、Amazon Web Servicesのセキュリティ設定を強化するためのガイドラインを提供しており、基本的な設定や検証可能な設定、アーキテクチャに依存しない設定に焦点を当てています。 対象となるAWSサービスには、IAMやIAM Access Analyzer、AWS Config、AWS CloudTrail、CloudWatch、Amazon SNS、S3、EC2、RDS、そしてVPCなどがあります。これらのサービスに対し、安全で信頼性の高い設定を確立するための指針を示しています。   PCI DSS v4.0 PCI DSS v4.0はクレジットカード情報を取り扱う企業向けのセキュリティ基準であり、クラウド環境におけるデータ保護の要件が厳格化されています。 インターネットの急速な発展に伴い、サイバー攻撃がますます複雑化し、カード情報の流出や不正利用のリスクが高まっています。カード情報が流出すると、成りすましによる不正利用などの経済的損害が発生する可能性があるため、PCI DSSは「理想的なセキュリティ」ではなく「最低限守るべき基準」として位置付けられています。 PCI DSS v4.0では、リスク分析の新たな取り組み、安全な暗号化方式の導入、パスワードの複雑性強化、多要素認証の実装など、セキュリティ対策が強化されています。   まとめ Prisma Cloudは、クラウド環境でのデータ保護と法令遵守を確実にするために、ISO 27001:2022、CIS AWS v.1.4、PCI DSS v4.0などの主要なコンプライアンス基準をサポートしています。これにより、企業は安心してクラウド技術を活用し、デジタルトランスフォーメーションを推進することができると考えられます。 また、当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp ご興味のある方は是非、お気軽にお問い合わせください。

クラウドベンダーと利用企業がそれぞれの責任を分担する「責任共有モデル」は、クラウドセキュリティの基本概念として広く認知されています。しかし、利用企業の中では具体的に「誰が」セキュリティの責任を負うべきなのでしょうか？ 情報セキュリティ担当部門なのか、それとも実際にクラウドを運用する部門なのか――この問いについて考察します。 ※本ブログでは、企業の情報セキュリティ部門とクラウド運用部門のどちらがパブリッククラウドのセキュリティ責任を担うべきかを論じています。ただし、企業の規模やクラウドの利用方法によっては、セキュリティ管理の階層がより細分化されているケースもあるため、自社の組織構造に合わせて読み替えていただければと思います。   パブリッククラウドのセキュリティリスクと影響 パブリッククラウドを利用する企業にとって、クラウド上で発生するセキュリティインシデントは重大なリスクです。 データ漏洩、不正アクセス、設定ミスによる情報公開などの問題が発生した場合、企業に与える影響は以下のような形で現れます。 財務的損失 報漏洩による賠償責任や罰則、ブランド価値の低下 事業継続への影響 システムダウンやデータ消失により業務が停止 顧客・取引先の信頼低下 データ流出等により企業への信頼が損なわれ、契約解除や取引縮小が発生 インシデント対応の負担増 調査・復旧・再発防止策の実施に膨大な時間とコストが必要 このような影響を踏まえると、企業内のどの部署が責任を持つべきなのかを明確にすることは極めて重要です。   情報セキュリティ担当部門の役割 一般的に、企業の情報セキュリティ担当部門は社内全体のセキュリティポリシーの策定や管理を担っています。 この部門は以下のような活動を行います。 セキュリティポリシーの策定と適用 社内全体のガイドラインを定め、適用を監督 リスク評価と対応策の検討 脅威分析を行い、必要な対策を実施 インシデント発生時の対応 影響範囲の調査、原因分析、再発防止策の策定 一方で、クラウド環境の具体的な設定管理や運用は担当しない場合が多く、技術的な詳細についてはクラウドの運用者に依存します。   クラウド運用部門の責任 クラウドを実際に運用する部門（IT部門やクラウド専門チーム）は、クラウド環境の設定や運用管理を担います。 そのため、セキュリティリスクの多くがこの部門の手に委ねられることになります。 適切なアクセス管理 IAMの設定、権限付与の管理 セキュリティ設定の維持 暗号化の適用、ネットワーク設定の監視 監視とインシデント対応 ログ分析やアラート対応 特にクラウドでは 設定ミス が大きなセキュリティリスクとなるため、実務レベルでセキュリティを担保するのは運用者の責任だともいえます。しかし、クラウド運用者にセキュリティの責任を集中させることには以下のような課題があります。 業務の幅広さによる負担 クラウド運用者はセキュリティだけを専門に扱っているわけではなく、システムの運用・保守、パフォーマンス監視、コスト管理など多岐にわたる業務を担当しています。 そのため、セキュリティの向上に特化した取り組みを行う時間やリソースを確保することが難しいという問題があります。 最新のセキュリティ情報を常に把握する難しさ クラウドサービスは頻繁にアップデートされ、新しいセキュリティ機能が追加されます。 例えば、AWSやAzureでは定期的にセキュリティ強化のための新機能がリリースされますが、これらを常に追い続け、適切に導入することは運用者にとって負担となります。また、新たなセキュリティ脅威も日々登場するため、運用者が最新の脅威動向を把握し、それに対応するのは容易ではありません。 責任の曖昧さによるリスク クラウド運用部門がセキュリティ対応を担当すると、情報セキュリティ部門との責任分担が曖昧になることがあります。 たとえば、セキュリティポリシーの策定は情報セキュリティ部門が担当するが、クラウドの実際の設定は運用者が行うという形になった場合、 「どこまでが運用者の責任で、どこからが情報セキュリティ部門の責任なのか」が不明瞭になり、対応が遅れる可能性があります。 スキルのばらつきによるリスク クラウド環境では、アクセス権限の管理、ネットワーク設定、暗号化の適用など、細かいセキュリティ設定が求められます。 経験豊富な運用者であれば適切な設定を行えますが、知識が不足している運用者の場合、設定ミスや見落としが発生しやすくなります。特に複数のクラウドサービス（AWS、Azure、GCPなど）を利用している場合、クラウドサービスの理解度によって大きく違いがでます。 結果として、システムの一部に脆弱性が残り、攻撃者に狙われる可能性が高まります。   結論 情報セキュリティ担当部門とクラウド運用部門のどちらが最終的な責任を持つべきなのか、という問いに対する答えは、「どちらも重要な責任を持つが、役割が異なる」という点にあります。 情報セキュリティ担当部門 企業全体のルールを定め、監督する責任 クラウド運用部門 実際の運用・設定管理を行い、セキュリティリスクを防ぐ責任 クラウド環境では技術的な管理がセキュリティの質を大きく左右するため、クラウド運用部門が重要な役割を果たしますが、それを監督する情報セキュリティ担当部門も不可欠です。企業内で明確な責任分担を定め、双方が連携して取り組むことが、クラウドセキュリティを確保する重要なポイントとなります。 ただし、これだけではクラウド運用者の負担が大きく、セキュリティの課題を根本的に解決することは困難です。そのため、 情報セキュリティ担当部門主導でクラウドセキュリティ製品の導入を積極的に検討することが、より効果的な解決策 となります。 特に、 CSPM（Cloud Security Posture Management） を活用することで、 クラウド環境のセキュリティ課題を効率的かつ継続的に解決することが可能となります。 CSPMが有効である理由 クラウド設定の継続的な監視と評価 CSPMはクラウド環境の設定ミスやポリシー違反を自動で検知し、推奨されるセキュリティ基準と比較しながら、リアルタイムで改善案を提示します。そのため、運用者が手動で監視する負担が減り、適切なセキュリティ管理が継続的に行えます。 クラウド環境ごとの統一的なセキュリティ管理 企業が複数のクラウド（AWS、Azure、GCPなど）を利用している場合、各クラウドサービスごとに異なるセキュリティ設定を管理するのは非常に困難です。CSPMを導入すれば、異なるクラウド環境を統一的に監視・管理し、セキュリティレベルのばらつきを防ぐことができます。 インシデント発生前のリスク軽減 多くのセキュリティインシデントは、設定ミスや限管理の不備によって引き起こされます。CSPMはこれらの問題を事前に検知し、脆弱な設定を未然に防ぐことで、インシデント発生リスクを低減できます。 CSPMの導入で、人的リソースと技術を組み合わせた最適なセキュリティ対策を クラウド運用者の責任だけに頼るのではなく、CSPMを活用することで、より効率的かつ継続的なセキュリティ管理が可能となります。 これにより、情報セキュリティ部門とクラウド運用部門の連携が強化され、負担を分散しながら適切なセキュリティ対策を実現することができます。   おわりに パブリッククラウドの活用が広がる中、セキュリティリスクへの対応を「人」に依存するのは限界があります。属人的な管理では対応の抜けやミスが発生しやすく、組織全体のセキュリティレベルを維持するのが難しくなります。そのため、自動化されたツールの活用が不可欠です。 最近では「CNAPP（Cloud-Native Application Protection Platform）」という概念が注目されていますが、まずは基本となるCSPMを導入し、確実なセキュリティ対策の第一歩を踏み出すことが重要です。CSPMを活用することで、クラウド環境の設定ミスや脆弱性を検出し、適切な対応を行うことが可能になります。そしてセキュリティ強化のためCNAPPの導入を検討していきましょう。CNAPPには複数のセキュリティの要素が含まれる（CSPMも含みます）ため計画的に導入することを推奨します。 当社ではクラウド診断サービスやマネージドCSPMサービスを提供していますので、ご興味のある方は是非、お気軽にお問い合わせください。 Smart One Cloud Security® パブリッククラウドのセキュリティ設定を診断/監視するマネージドCSPMサービスです。Palo Alto Networks社Prisma Cloud（CSPM機能）を使い易く、簡単に導入いただけます。 www.scsk.jp マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp

最近、周りで筋トレをする人が本当に多いんです。 同期の中には、ベンチプレス140kgを挙げられると豪語するゴリマッチョや、フィジーク大会に出場する本格派まで現れる始末。 ついには、私の母までちょこっと筋トレできるライトなジムに通い始めてしまいました。 そんな筋トレブームを横目に、私が力を入れているのが「Azure Bicep」です。  IaCを用いた強靭で美しい環境を作り上げることに情熱を燃やしています！ Bicepとは Bicepを和訳すると上腕二頭筋になります。いわゆる力こぶ💪のことです。 bicepの意味・使い方・読み方 | Weblio英和辞書 なぜ力こぶ？名前の由来が気になります。 元々Azureでは腕のアーム（ARM：Azure Resource Manager）がインフラ構築する際のテンプレートとして利用されていたが、これからは力こぶでさらにパワーを強調するぞ！！などと開発者は考えたのかもと想像してしまいます。 真相は定かではありませんが、コードでインフラを構築する力強さを表現していると感じています。 JSON形式のARMテンプレートは記述が冗長になりやすく、可読性も低い課題がありました。 そこで開発されたのがBicepです。ARMテンプレートをよりシンプルに、より直感的に記述できるように設計されたDSL（ドメイン固有言語）なのです。 Bicep とは - Azure Resource Manager インフラストラクチャを Azure にデプロイするための Bicep 言語を理解します。 JSON を使用してテンプレートを開発する場合に比べてオーサリングがしやすくなります。 learn.microsoft.com   ポータル操作と比較した利点 Bicepに限らずですが、私が感じたIaCの利点は ミスなし 、 複製よし 、の2点です。 ミスなし：ヒューマンエラーの抑制 ポータル上をポチポチしながら構築すると、どうしてもミスが発生します。 設定漏れや間違った項目の選択など色々な事象が起き得ます。 IaC なら「一度正しい設定をコード化すれば、後は何度デプロイしても同じ構成が再現される」という特徴があるので、人間の手による作業が減る分の品質向上に寄与できるのです。   複製よし：リソースの複製が簡単 実際の案件では、同じような設定のリソースを何度も作成する必要があります。 仮想マシン2台、ストレージ1台、データベース1台、…みたいな少量だけ作成することはあり得ないですよね。 同じような設定のコードをコピーしてパラメータを変更すれば、瞬時にリソースを複製できます。 私が災対環境構築に携わった際も、本番環境の Bicep コードを流用することでスムーズに構築できました。    ただしデメリットもあります。それは 学習コストが高い こと。 ツールの設定や記述方法などに慣れる必要があり、初学者だと厳しいところがあります。 公式ドキュメント見ながらコード記述するのは、私もかなり骨が折れました。 Azure リソース リファレンス - Bicep, ARM template & Terraform AzAPI reference Bicep、Azure Resource Manager テンプレート、Terraform AzAPI プロバイダーを使用してリソースをデプロイするためのリファレンス ドキュメントを参照してください。 すべてのリソースの種類を表示します。 learn.microsoft.com また私の案件では、災対切り替えを行うのは私ではなく運用チームです。 その際にBicepでやるのは難しいので、ポータル操作で対応するとの噂を聞きました。 ちょっと悲しいですが、災対切り替えがスムーズに行えない可能性を考えればしょうがないかもと考えています。   ARMテンプレートと比較 Bicep が ARM テンプレートよりも優れている点は、その 可読性 と 記述の容易さ にあります。 具体的にコードを比較してみましょう。 今回は、以下の要件でストレージアカウントを作成する場合を例に、Bicep と ARM テンプレートのコードを比較します。 要件のパラメータ 名前：sttomioka88 リージョン：東日本リージョン SKU：Standard_LRS ストレージの種類：StorageV2 アクセス層：Hot Bicepのコード param location string = 'japaneast' param storageAccountName string = 'sttomioka88' resource storageAccount 'Microsoft.Storage/storageAccounts@2024-01-01' = { name: storageAccountName location: location sku: {   name: 'Standard_LRS' } kind: 'StorageV2' properties: {   accessTier: 'Hot' } } ARMテンプレート（JSON）のコード {   "$schema": " https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#" , "contentVersion": "1.0.0.0", "parameters": {   "location": {     "type": "string",     "defaultValue": "japaneast"   },   "storageAccountName": {     "type": "string",     "defaultValue": "sttomioka88"   } }, "resources": [   {     "type": "Microsoft.Storage/storageAccounts",     "apiVersion": "2024-01-01",     "name": "[parameters('storageAccountName')]",     "location": "[parameters('location')]",     "sku": {       "name": "Standard_LRS"     },     "kind": "StorageV2",     "properties": {       "accessTier": "Hot"     }   } ] } コードを比較して分かること 直感的な構文 Bicep ではパラメータの参照に”[parameters(‘storageAccountName’)]”のような式を使う必要がありません。 paramで指定した値を直接参照できるのです。 そのためコードの可読性が向上してます。 ちなみに.bicepparamファイルを作れば、パラメータの管理もさらに綺麗になります。案件でもこの運用をしてました。 ネスト構造の簡略化 Bicep ではリソースのプロパティをネスト構造で記述する必要がなくなり、より容易な構造で記述できます。 カッコが無い分コードの見通しが良くなります。 そもそもJSON形式にカッコが多すぎますので、本当にあって良かったBicep。 これらの違いによりBicep を使うことで、ARM テンプレートよりも短時間で簡単にインフラをコード化することができます。 次のセクションでは、実際に Bicep を使ってストレージを作成してみますね。   Bicepでストレージをデプロイしてみる VSCodeで.bicepファイルを作成した後、右上の雲のマークからデプロイを開始できます。           Change Scopeでリソースグループを選択します。           後はDeployを押下するだけで、デプロイが完了します。Succeededが表示されていれば成功です。           Azureのポータルに確認しに行きますと、リソースが作成されていることが分かります。         さいごに Bicepの公式ドキュメントみるとパスが「Learn/紺碧/リソースマネージャー/上腕二頭筋/」になってます。             Azureってこういう変な表記になっていることが多い気がします。 常に英語のドキュメントで確認できたらもっとAzureライフが捗るなぁと思いました。

はじめに 当記事は、 日常の運用業務（NW機器設定）の自動化 により、 運用コストの削減　および　運用品質の向上 　を目標に 「Ansible」 を使用し、様々なNW機器設定を自動化してみようと　試みた記事です。 Ansibleは、OSS版（AWX）＋OSS版（Ansible）を使用しております。   PaloAltoの「Objects-アドレス」の登録／変更／削除を実施してみた 事前設定 Templateを作成し、インベントリーと認証情報を設定する。 インベントリー：対象機器（ホスト）の接続先を設定。　※ホストには以下変数で接続先IPを指定 ansible_host: xxx.xxx.xxx.xxx 認証情報：対象機器へのログイン情報（ユーザ名／パスワード）を設定。 ユーザ名は　　変数：ansible_user　　　に保持される パスワードは　変数：ansible_password　に保持される   Playbook作成（YAML） 使用モジュール paloaltonetworks.panos.panos_address_object 　を使用。 ※参考ページ：https://galaxy.ansible.com/ui/repo/published/paloaltonetworks/panos/content/module/panos_address_object/   接続情報（provider）の設定 providerには、ip_address／username／password　の指定が必要。 vars: provider:   ip_address: '{{ ansible_host }}'　　　←　インベントリーのホストで設定   username: '{{ ansible_user }}'　　　　←　認証情報で設定   password: '{{ ansible_password }}'　　←　認証情報で設定   Objects-アドレスの登録 接続情報とアドレス情報を指定して登録（state: ‘present’）を行う。 - name: Add Address1 paloaltonetworks.panos.panos_address_object: provider: '{{ provider }}' name: 'test_address001' address_type: 'ip-netmask' value: '192.168.10.0/24' description: 'address_ip-netmask' tag: ['test'] state: 'present' register: wk_result 実行結果：対象のアドレスが登録された。　※Ansibleの実行結果（diff）を抜粋 "before": "", "after": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_address001\">\n\t<ip-netmask>192.168.10.0/24</ip-netmask>\n\t<description>address_ip-netmask</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n"   Objects-アドレスの変更　※登録のつづき 接続情報とアドレス情報を指定して　登録されたアドレスの変更（ state: ‘replaced’ ）を行う。　 ※replacedの場合は、既存設定の置き換えとなる - name: Change Address1 paloaltonetworks.panos.panos_address_object: provider: '{{ provider }}' name: 'test_address001' address_type: 'ip-netmask' value: '192.168.20.0/24' description: 'address_ip-netmask' # tag: ['test'] state: 'replaced' register: wk_result 実行結果：登録時のtag指定ありのアドレスが、Rreplaedによりtag指定なしのアドレスに変更された。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_address001\">\n\t<ip-netmask>192.168.10.0/24</ip-netmask>\n\t<description>address_ip-netmask</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_address001\">\n\t<ip-netmask>192.168.20.0/24</ip-netmask>\n\t<description>address_ip-netmask</description>\n</entry>\n"   接続情報とアドレス情報を指定して　登録されたアドレスの変更（ state: ‘merged’ ）を行う。　 ※mergedの場合は、既存設定の上書きとなる - name: Change Address2 paloaltonetworks.panos.panos_address_object: provider: '{{ provider }}' name: 'test_address001' address_type: 'ip-netmask' value: '192.168.30.0/24' # description: 'address_ip-netmask' tag: ['test'] state: 'merged' register: wk_result 実行結果：上記変更時のtag指定なしのアドレスが、mergedによりtag指定ありのアドレスに変更された。また、アドレス情報にdescriptionを指定しなくても、既存設定が維持されていることを確認。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_address001\">\n\t<ip-netmask>192.168.20.0/24</ip-netmask>\n\t<description>address_ip-netmask</description>\n</entry>\n", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_address001\">\n\t<ip-netmask>192.168.30.0/24</ip-netmask>\n\t<description>address_ip-netmask</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n"   Objects-アドレスの情報収集　※変更のつづき 接続情報とアドレスを指定して情報収集（state: ‘gathered’）を行う。 - name: Get Address Info paloaltonetworks.panos.panos_address_object: provider: '{{ provider }}' name: 'test_address001' state: 'gathered' register: wk_result 実行結果：対象アドレスの情報が取得できた。　※Ansibleの実行結果（gathered_xml）を抜粋 "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_address001\">\n\t<ip-netmask>192.168.30.0/24</ip-netmask>\n\t<description>address_ip-netmask</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n"O   Objects-アドレスの削除　※変更のつづき 接続情報とアドレスを指定して削除（state: ‘absent’）を行う。 - name: Delete Address1 paloaltonetworks.panos.panos_address_object: provider: '{{ provider }}' name: 'test_address001' state: 'absent' register: wk_result 実行結果：対象のアドレスが削除された。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_address001\">\n\t<ip-netmask>192.168.30.0/24</ip-netmask>\n\t<description>address_ip-netmask</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n", "after": ""   最後に 「Ansible」の「paloaltonetworks.panos.panos_address_object」を使用し、「Objects-アドレス」の登録／変更／削除　および　情報収集ができたことは良かった。何らかの変更申請の仕組みと連携することで、より　設定変更の自動化　が活用できるようになると考える。 現状　設定情報がベタ書きで使い勝手が悪いので、今後　設定内容をINPUTする仕組みを試みたいと思います。 また、引続き　他にも様々なNW機器設定を自動化してみようと思います。

みなさん、こんにちは。SCSK株式会社の津田です。 LifeKeeperではサービスをリソース化してHAクラスタの保護対象とする際、どのオプション製品を使うか？ というのはLifeKeeperの設計フェーズでのポイントの一つになるかと思います。 今回はQuick Service Protection(以下QSP)についてご紹介します！ オプション製品についておさらい はじめに、 第２回　「LifeKeeper」で可用性を高められるミドルウェアはこれだ！ でも少しお伝えしている オプション製品についておさらいとなります。 LifeKeeperではサービスをHAクラスタの保護対象とする際、ARKというスクリプト集で起動・停止・監視・回復を制御します。 サイオステクノロジー社により様々なサービスに沿った専用のARKが用意されてはいますが、 もし保護対象にしたいサービスの専用ARKがない場合は、以下の選択肢があります。 選択肢➀ Generic ARK 選択肢➁ QSP 有償オプションの専用ARKとは異なり、上記選択肢はどちらも無償オプションとなります。 「Generic ARK」を利用する場合の特徴として、アプリケーションの起動・停止・監視・回復(任意)を制御するスクリプトの作成が必要となります。 サイオステクノロジー社よりベースとなるスクリプトは提供されているものの、スクリプトを準備することはGenericARKを利用する上でのハードルとなるケースがあります。 対する 「QSP」を利用する場合の特徴として、OSの機能(init,systemdやWindowsサービス)で起動・停止・監視・回復を行います。 そのためスクリプトの作成は不要で簡単にLinux、Windows上の一般的なサービスをLifeKeeperの保護対象とすることができるんです！ QSPメリット・デメリット 以下QSPの主なメリット・デメリットをあげていきます。 QSP検討の際の参考となれば幸いです。 メリット ・スクリプトの準備が不要 　 GenericARKのようなスクリプトの事前準備は不要となります。 ・設計・構築スケジュール短縮が見込める 　 スクリプトの準備不要でGUIより簡単にQSPのリソースを構築することができます。 ・導入コストを抑えられる 　 設計・構築スケジュール短縮に加え、QSPは無償オプションとなりますのでコストを抑えることができます。 デメリット ・サービスがinit、systemd、Windowsサービスに対応していない場合は利用できない 　 (※init,systemd、Windowsサービスに対応していてもQSPが利用できない場合があります。注意点として後述します。) ・専用ARKが用意されているサービスに対しては利用できない ・OSの機能による簡単な監視処理しかできない 　 監視処理はOS機能によるステータスでの判断となるため、細かな監視は行えません。 　 ※監視内容を細かく設定したい場合は、Generic ARKの利用が適しています。 QSP利用前の注意点 前述の「QSPメリット・デメリット」でも少し記載しましたが、 一部のサービスについては、init、systemd、Windowsサービスに対応していてもQSPが利用できない場合もありますので注意が必要です。 QSPで保護対象としたいサービスがある場合は、一度以下で確認されることをおすすめします。 ▼サイオステクノロジー社公開のHA化で実績のある対応ソフトウェア一覧です。 https://bccs.sios.jp/lifekeeper/sw.html ※「ARK以外の保護方法」欄にQSPの記載があるものはLifeKeeperでのリソース化実績があるものになります。 QSPの記載はないが最新の実績状況を知りたい、この表にないソフトウェアのサービスを保護したいという場合は、 サイオステクノロジー社またはSCSKにお気軽にお問合せください。 ▼サイオステクノロジー社公開のLinuxのQSPの保護対象外サービスの一覧です。 https://lkdkuserportal.sios.jp/hc/ja/articles/900000555366 まとめ 今回はQSPについてご紹介いたしました。 以下に該当する場合はQSPでのサービス保護をぜひご検討頂ければと思います！ ・保護対象のサービスはOS機能(init、systemd、Windowsサービス)で制御可能 ・スクリプト作成の手間を省きたい ・監視はサービスの起動・停止確認だけでよい 　 詳しい内容をお知りになりたいかたは、以下のバナーからSCSK Lifekeeper公式サイトまで

LifeKeeperでは管理コンソールを用いて、設定投入やパラメータ確認、手動切替などを手軽に行うことが可能です。 今回は、LifeKeeperの管理コンソールである「LKWMC」について解説していきます。 概要 LifeKeeper Web Management Console (LKWMC) は、Webベースの管理コンソールです。 LKWMCを使用することにより、ブラウザを通じてクラスタの管理や操作、監視を行うことができ、GUIを利用することで、より直感的にLifeKeeperの操作が可能になります。 LKWMCは、従来の管理コンソールと比較し、LifeKeeper専用のGUIアプリケーションをクライアントPCへインストールする必要がなく、Webブラウザーを利用して多様なデバイスからアクセス可能です。 また、LifeKeeperノードにログイン(sshなど)したり、クライアントに専用のGUIアプリケーションを起動する必要もありません。   仕組み 以下イメージ図です。 LKWMCでは、LifeKeeperのクラスターを構成する各サーバーへ、[GUIサーバー]と、[REST APIサーバー]をインストールします。 GUIを利用する際には、Webブラウザーを利用しアクセスを行います。 Webブラウザーの画面上で各種操作を実行すると、[GUIサーバー]がクラスター上の各サーバーの[REST APIサーバー]と通信することで、LifeKeeperが保持する各種リソース状態の取得・操作が可能です。 これにより、LifeKeeperクラスターサーバー上で直接動作する専用のJavaベースのGUIクライアントアプリケーションに（例えば、SSH X11転送またはVNCセッションを介して）接続する必要がなくなります。   GUIサーバーとは LKWMCのGUI(Graphical User Interface)部分をWebアプリケーションとして提供します。 また、LKWMCのGUI上で行った各種操作の命令をLifeKeeperクラスター上の別のサーバーへ転送する機能を持っています。   REST APIサーバーとは LifeKeeperコアの各種操作・リソース管理などの機能をWeb APIとして提供します。 LKWMCを利用する際には、LifeKeeperクラスターを構成する全てのサーバー上に同一のバージョンの[REST APIサーバー]がインストールされている必要があります。   インストールについて インストール方法 対象ノードにインストールスクリプトを格納し、実行すればOKです。 # /lkwmc/sios-lkwmc-1.2.0/install Installing LifeKeeper Web Management Console (LKWMC) v1.2.0... -- Performing pre-installation checks... -- Installing supporting files... ～～以下省略～～ Starting LifeKeeper Web Management Console... Created symlink /etc/systemd/system/multi-user.target.wants/lifekeeper-wmc.service → /usr/lib/systemd/system/lifekeeper-wmc.service. Done Note: LifeKeeper Web Management Console must be installed on all servers in the LifeKeeper cluster. To connect to the LifeKeeper Web Management Console from a web browser: https：//xxxx:5110 # 上記のような出力がされます。 インストールが成功したことを確認するには、以下のコマンドを用いて確認できます。 lifekeeper-apiサービスとlifekeeper-wmcサービスが正常に実行されている(出力結果がある)ことを確認します。 # systemctl status lifekeeper-api # systemctl status lifekeeper-wmc   起動と停止について lifekeeper-apiおよびlifekeeper-wmc systemdサービスは REST APIおよびGUIサーバーパッケージの初期インストール時に起動され、有効になります。 それらのサービスが有効になると、サーバーの再起動時にsystemdによって自動的に再起動されます。 systemctlコマンドを使用して、上記サービスを停止したり、 システムの再起動時にサービスが自動的に再起動することを無効化することができます。 コマンド詳細は以下のサイトに記載がありますので、ご参照ください。 LKWMCサービスの起動と停止 – LifeKeeper for Linux LIVE – 9.8.1   起動方法 インストールが完了しましたら、Webブラウザーのアドレス欄に、 下記を入力することでLKWMCの画面が表示されます。 https://{該当ノードのIPアドレス・ホスト名}:5110/lkgui/#/   各項目解説 セットアップが完了しましたら、各項目で設定を入れていきます。 今回は各項目ごとの解説を行っていきます。 こちらが項目の一覧となります。   コミュニケーションパス コミュニケーションパスとは、各ノード間でお互いの状態等の情報をやり取りするための経路になります。 コミュニケーションパスの項目では、コミュニケーションパスの作成、フェイルオーバーする際のプライオリティの設定、ステータスの確認をすることが可能です。   プロパティー(サーバー) ノード情報やLifeKeeperのバージョン確認などのパラメータを確認できます。 また、オペレーション＞プロパティ-の編集　から各種情報の修正も可能です。   サインイン状況 各ノードのサインイン状況が確認できます。 なお有効期限と記載されているのは、ノードにインストールされているLifeKeeperライセンスの有効期限やLKWMCの有効期限ではなく 対象ノードにサインインした時間を表記しているようです。   リソースツリー 各リソースの状態(どのノードがPrimaryであるかや、ステータスがALiveかDeadであるかなど)の確認を視覚的にわかりやすく確認できます。 また、リソースの作成/削除やスイッチオーバー/スイッチバックの動作、リソースの依存関係などの各設定を「オペレーション」から設定・操作が可能となります。   プロパティー(リソース) 各ノードの各リソースの設定値を確認できます。 リソース項目の「▼」にて確認したいリソースを選択し、そこからマウントポイントやステータスなどの情報を確認できます。 また、オペレーションからプロパティーの修正をすることも行えます。   ログ ローカルサーバーの箇所で確認したいノードを選択し、各ノードのログを確認できます。 フォントサイズやログ出力の行数を調整できます。 また、検索窓より、確認したい内容のログの検索も行えます。   ライセンス インストールされているライセンスについて確認できます。 ライセンスタイプに併記される情報は以下の種類があります。 UNLICENSED LifeKeeper Coreのライセンスが適用されている状態 EVAL 評価版ライセンスが適用されている状態 PERMANENT オプションRecovery Kitのライセンスが適用されている状態 NEEDED オプションRecovery Kit のライセンスが適用されていない状態 以上がLKWMCの設定項目になります。   最後に 今回はLifeKeeperの管理コンソールである「LKWMC」について解説をしました。 実際の管理画面を見たことが無かった方や、これから利用を検討している方に操作するイメージを持っていただければ幸いです。 LifeKeeperに関してより詳しい情報をお求めの方は、下記バナーを通じてお問い合わせください。      

こんにちは。SCSKのふくちーぬです。 私が所属する技術戦略本部では、『2030 共創ITカンパニー』の実現に向けて、全社技術戦略の策定や先進技術を開拓し、新たな価値創出・社会実装に向けた様々な取り組みを進めております。 その中でも技術戦略本部では、「Dify」を触れる環境を全社員に提供して、技術検証に加えて高度デジタル人材の育成を促進する取り組みをしています。 SCSKグループ技術戦略 技術ビジョン2030 ｜ SCSK株式会社 SCSKグループは、お客様やパートナーと共に社会課題の解決に貢献するビジネスを作り出す「2030年 共創ITカンパニー」の実現に向けて、「コア事業の高度化・拡大」、「お客様のビジネス成長への貢献」、「社会への新たな価値創出」への取り組みを推... www.scsk.jp 本記事では、OSSのLLMアプリケーション開発プラットフォーム「Dify」をAWS上でホスティングし全社展開している知見やRAGアプリケーションを紹介します。 Difyとは 各種LLM（大規模言語）モデルを活用して、GUIベースで簡単に生成Aiアプリケーションを開発できるツールです。 Dify クラウドサービス クラウドサービスとして提供される完全マネージ型のSaaSです。AWSアカウントと同様にテナント（アカウント）を分けたり、多様な認証方法が用意されISO 27001:2022認証(ISMS)を始めとしたコンプライアンスも順守されているため、エンタープライズの大規模利用に向いています。 Dify AI · Plans and Pricing The next-gen development platform - Easily build and operate generative AI applications. Create Assistants API and GPTs ... dify.ai Dify コミュニティ版 オープンソースとして提供されるセルフホスティング型のソリューションです。クラウドサービスとは異なり、Dify本体のサービス利用料はかかりませんが、ホストティングしている基盤の利用料や運用管理は発生します。またテナントを分割することはできず、認証方法が限定（メールアドレス＋パスワード）されています。その他ライセンスの利用条項が記載しているので、自社利用する際はご参照の上構築ください。 Dify Community | Dify docs.dify.ai アーキテクチャ ユーザーは、HTTPS通信でDify Webアプリケーションにアクセスします。 ALB及びACMを利用したHTTPS通信 ALBのセキュリティグループでは、IPアドレスでのアクセス制御 Difyアプリケーションは、EC2内のDocker-Composeコマンドで稼働 構築手順 弊社で全社展開しているDify環境のノウハウを活かして、今回は個人でも扱いやすいDifyセルフホスティング環境を構築する手順をご紹介します。 Amazon Route 53 のドメイン取得 Route 53 でドメインを取得していきます。 今回は、Route 53 で提供されるTLDの中で最安の「.click」を購入しています。3$/年の格安料金です。 連絡先情報を入力します。 10分程待つと、AWS側でリクエストが承認されて、ステータスが「成功」になります。 これで、ドメインは取得は完了です。 証明書の取得 次にドメインに紐づいた証明書を取得します。 ACMのコンソールに切り替えます。「リクエスト」を押下します。 「パブリック証明書をリクエスト」を選択して、「次へ」を押下します。 Route 53 で取得したドメイン名を入力します。検証方法、キーアルゴリズムはデフォルトの設定のままで構いません。 「リクエスト」を押下します。 ACM証明書の作成は完了しました。Route 53 とのDNS検証をするために、CNAMEレコードを登録します。「Route 53 でレコードを作成」を押下します。 「レコードを作成」を押下します。 Route 53 とのDNS検証が完了するまで、10分程待ちます。 Route 53 の検証が成功すれば、ステータスが「発行済み」に変更されます。 これで、証明書の取得は完了です。 AWS CloudFormtion テンプレート テンプレートで指定する各種パラメータの値を控えておいてください。 DifyVersion 下記サイトをご確認し、指定のバージョンを選んでください。 Tags · langgenius/dify Dify is an open-source LLM app development platform. Dify's intuitive interface combines AI workflow, RAG pipeline, agen... github.com DockerComposeVersion Tags · docker/compose Define and run multi-container applications with Docker - Tags · docker/compose github.com ACMCertificateArn 発行したACMのARNを指定してください。 HostedZoneId Route 53 パブリックホストゾーンのIDを指定してください。 DomainName Route 53 で登録したドメイン名を指定してください。 その後、以下のCloudFormtionテンプレートをデプロイしてください。 AWSTemplateFormatVersion: '2010-09-09' Description: Dify CloudFormation Template with ALB and EC2 (HTTPS) Parameters: ProjectName: Type: String Default: dify Description: Project name used as prefix for resources VpcCIDR: Type: String Default: 10.0.0.0/16 PubSubnet1CIDR: Type: String Default: 10.0.0.0/24 PubSubnet2CIDR: Type: String Default: 10.0.1.0/24 PriSubnet1CIDR: Type: String Default: 10.0.10.0/24 PriSubnet2CIDR: Type: String Default: 10.0.11.0/24 AllowedCIDR: Type: String Default: 0.0.0.0/0 AmazonLinuxAMI: Type: AWS::SSM::Parameter::Value Default: /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-6.1-x86_64 DifyVersion: Type: String Default: 1.1.0 DockerComposeVersion: Type: String Default: v2.35.1 ACMCertificateArn: Type: String Description: ACM Certificate ARN for HTTPS HostedZoneId: Type: String Description: Route 53 Hosted Zone ID DomainName: Type: String Description: Domain name Resources: VPC: Type: AWS::EC2::VPC Properties: CidrBlock: !Ref VpcCIDR EnableDnsHostnames: true EnableDnsSupport: true Tags: - Key: Name Value: !Sub "${ProjectName}-vpc" PubSubnet1: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC AvailabilityZone: !Select [0, !GetAZs ''] CidrBlock: !Ref PubSubnet1CIDR MapPublicIpOnLaunch: true Tags: - Key: Name Value: !Sub "${ProjectName}-pub-subnet-1" PubSubnet2: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC AvailabilityZone: !Select [1, !GetAZs ''] CidrBlock: !Ref PubSubnet2CIDR MapPublicIpOnLaunch: true Tags: - Key: Name Value: !Sub "${ProjectName}-pub-subnet-2" PriSubnet1: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC AvailabilityZone: !Select [0, !GetAZs ''] CidrBlock: !Ref PriSubnet1CIDR Tags: - Key: Name Value: !Sub "${ProjectName}-Pri-subnet-1" PriSubnet2: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC AvailabilityZone: !Select [1, !GetAZs ''] CidrBlock: !Ref PriSubnet2CIDR Tags: - Key: Name Value: !Sub "${ProjectName}-Pri-subnet-2" InternetGateway: Type: AWS::EC2::InternetGateway Properties: Tags: - Key: Name Value: !Sub "${ProjectName}-igw" VPCGatewayAttachment: Type: AWS::EC2::VPCGatewayAttachment Properties: VpcId: !Ref VPC InternetGatewayId: !Ref InternetGateway PubRouteTable: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VPC Tags: - Key: Name Value: !Sub "${ProjectName}-pub-rt" PubRoute: Type: AWS::EC2::Route DependsOn: VPCGatewayAttachment Properties: RouteTableId: !Ref PubRouteTable DestinationCidrBlock: 0.0.0.0/0 GatewayId: !Ref InternetGateway PubSubnet1RouteTableAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PubSubnet1 RouteTableId: !Ref PubRouteTable PubSubnet2RouteTableAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PubSubnet2 RouteTableId: !Ref PubRouteTable EIP: Type: AWS::EC2::EIP Properties: Domain: vpc Tags: - Key: Name Value: !Sub "${ProjectName}-eip" NATGateway: Type: AWS::EC2::NatGateway Properties: AllocationId: !GetAtt EIP.AllocationId SubnetId: !Ref PubSubnet1 Tags: - Key: Name Value: !Sub "${ProjectName}-natgw" PriRouteTable: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref VPC Tags: - Key: Name Value: !Sub "${ProjectName}-Pri-rt" PriRoute: Type: AWS::EC2::Route Properties: RouteTableId: !Ref PriRouteTable DestinationCidrBlock: 0.0.0.0/0 NatGatewayId: !Ref NATGateway PriSubnet1RouteTableAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PriSubnet1 RouteTableId: !Ref PriRouteTable PriSubnet2RouteTableAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PriSubnet2 RouteTableId: !Ref PriRouteTable ALBSecurityGroup: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: Allow HTTPS from AllowedCIDR VpcId: !Ref VPC SecurityGroupIngress: - IpProtocol: tcp FromPort: 443 ToPort: 443 CidrIp: !Ref AllowedCIDR Tags: - Key: Name Value: !Sub "${ProjectName}-alb-sg" EC2SecurityGroup: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: Allow traffic from ALB only VpcId: !Ref VPC SecurityGroupIngress: - IpProtocol: tcp FromPort: 80 ToPort: 80 SourceSecurityGroupId: !Ref ALBSecurityGroup SecurityGroupEgress: - IpProtocol: -1 CidrIp: 0.0.0.0/0 Tags: - Key: Name Value: !Sub "${ProjectName}-ec2-sg" ALB: Type: AWS::ElasticLoadBalancingV2::LoadBalancer Properties: Name: !Sub "${ProjectName}-alb" Subnets: - !Ref PubSubnet1 - !Ref PubSubnet2 SecurityGroups: - !Ref ALBSecurityGroup Scheme: internet-facing LoadBalancerAttributes: - Key: idle_timeout.timeout_seconds Value: '60' Type: application Tags: - Key: Name Value: !Sub "${ProjectName}-alb" ALBTargetGroup: Type: AWS::ElasticLoadBalancingV2::TargetGroup Properties: Name: !Sub "${ProjectName}-tg" VpcId: !Ref VPC Protocol: HTTP Port: 80 TargetType: instance Targets: - Id: !Ref Instance HealthCheckProtocol: HTTP HealthCheckPath: /signin Tags: - Key: Name Value: !Sub "${ProjectName}-tg" ALBListener: Type: AWS::ElasticLoadBalancingV2::Listener Properties: Certificates: - CertificateArn: !Ref ACMCertificateArn DefaultActions: - Type: forward TargetGroupArn: !Ref ALBTargetGroup LoadBalancerArn: !Ref ALB Port: 443 Protocol: HTTPS InstanceRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: [ec2.amazonaws.com] Action: ['sts:AssumeRole'] ManagedPolicyArns: - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore - arn:aws:iam::aws:policy/AmazonBedrockFullAccess InstanceProfile: Type: AWS::IAM::InstanceProfile Properties: Roles: [!Ref InstanceRole] Instance: Type: AWS::EC2::Instance Properties: ImageId: !Ref AmazonLinuxAMI InstanceType: t3.medium IamInstanceProfile: !Ref InstanceProfile SubnetId: !Ref PriSubnet1 SecurityGroupIds: [!Ref EC2SecurityGroup] Tags: - Key: Name Value: !Sub "${ProjectName}-ec2" UserData: Fn::Base64: !Sub | #!/bin/bash sudo dnf install -y git docker sudo systemctl enable --now docker sudo usermod -aG docker ec2-user sudo curl -L "https://github.com/docker/compose/releases/download/${DockerComposeVersion}/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose sudo chmod +x /usr/local/bin/docker-compose sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose cd /opt sudo git clone https://github.com/langgenius/dify.git cd /opt/dify sudo git checkout ${DifyVersion} cd /opt/dify/docker sudo cp .env.example .env docker-compose up -d Route53Record: Type: AWS::Route53::RecordSet Properties: HostedZoneId: !Ref HostedZoneId Name: !Ref DomainName Type: A AliasTarget: DNSName: !GetAtt ALB.DNSName HostedZoneId: !GetAtt ALB.CanonicalHostedZoneID Outputs: InitialAccessURL: Description: Initial access URL for Dify Value: !Sub "https://${DomainName}/install" LoginURL: Description: Login URL for Dify Value: !Sub "https://${DomainName}/signin" CloudFormationでステータスが「CREATE_COMPLETE」になっていれば、環境構築は完了です。 Amazon Bedrock でのモデル有効化 今回は、以下のモデルを有効しております。 初めてBedrock内のモデルを利用する方は、下記手順に沿って実施ください。 Add or remove access to Amazon Bedrock foundation models - Amazon Bedrock Amazon Bedrock で基盤モデルを使用する前に、そのモデルへのアクセスをリクエストする必要があります。モデルへのアクセスが不要になった場合は、そのモデルからアクセスを削除できます。 docs.aws.amazon.com Difyの設定 管理者アカウントの作成 CloudFormationテンプレート内に記載してある、以下のURLから初期ログインしていきます。 初回ログイン時のみ、以下のURLにて管理者アカウントを作成します。 └https://<ドメイン名>/install  「セットアップ」を押下したら、ログインに進みます。 ログイン これ以降のアクセスは、以下のURLを利用します。 └https://<ドメイン名>/signin 先程のログイン情報でログインをしてください。   モデルの有効化 今回は、Amazon Bedrock経由でモデルを利用します。ユーザーアイコンを押下し、「設定」を押下します。 その後、「モデルプロバイダー」を押下します。 「セットアップ」を押下します。 CloudFormationテンプレートをデプロイした”リージョン”と、今回利用する”モデルID”を入力します。 以下のように、AWSアカウント内で利用可能なモデルが表示されればアプリケーション作成の準備が整いました。     DifyでRAGアプリケーションを構築 今回は、RAG ON/OFFができるチャットアプリケーションを開発しました。 RAG(Retrieval-Augmented Generation、検索拡張生成)とは 今では、生成AI・LLM（Large Language Model、大規模言語モデル）がエンタープライズでも多く利用されています。LLMは、事前にある時点での学習データを大量に読みこませています。その中での課題の一つに、LLMが社内情報や最新情報にもとづいた回答を生成できないことです。この問題を解決するための技術が、RAG(Retrieval-Augmented Generation、検索拡張生成)です。 RAGを利用することで、欲しい情報を検索して抽出し、その内容をもとに生成AIに回答させることができます。これを応用すると、生成AIは学習済の情報だけではなく、未学習の情報からも回答を生成することができます。 ナレッジの作成 RAGの例として、弊社のプレスリリースを参照させた汎用的なチャットアプリケーションを作成してみます。 RAGで参照元となるPDFファイルをナレッジに登録します。 Difyのトップページ上部にある、「ナレッジ」を押下します。 「ナレッジを作成」を押下します。 「テキストファイルからインポート」を選択し、該当のファイルをドラッグ&ドロップでアップロードします。 今回は、弊社のプレスリリース（メジャーリーグベースボール(MLB™)とオフィシャルパートナー契約を締結）をPDF資料として利用しました。 https://www.scsk.jp/news/2025/pdf/20250227_2.pdf アップロードが完了したら、「次へ」を押下します。 下記の設定を選択後、「保存して処理」を押下します。 　チャンク設定：自動 ⇒チャンクとは、小さな文章のかたまりのことです。AIが理解しやすいサイズに、文章を分割します。 　インデックスモード： ⇒AIが情報を素早くみつけさせるための、索引を作成します。 　検索設定： ⇒単語そのものを探す「全文検索」と、意味や内容が類似しているものを探す「ベクトル検索」を組み合わせています。 ナレッジが作成だれたら、「ドキュメントに移動」を押下します。 以下のように、チャンクごとに文章を確認することができます。ナレッジの作成は完了です。     ワークフローの作成 スタジオ内ではアプリケーションを一から作成することもできます。また、あらかじめ用意されたテンプレートから簡単に作成することもできます。   Difyでは、GUIで以下のようなフローをノーコードで作成することが可能です。 本アプリケーションでは、2か所で生成AIモデルを利用しています。 検索：ドキュメントを数値ベクトルに変換して、意味的に関連する情報を検索するために埋め込みモデルを使用しています。      ⇒amazon.titan-embed-text-v1（Amazon社がBedrockのみで提供。） テキスト生成：検索結果を基に、日本語で自然で正確な回答を作成するためにテキストモデルを使用しています。      ⇒anthropic.claude-3-5-sonnet-20240620-v1:0（Anthropic社が提供しているClaude 3シリーズの中規模モデル。） 作成したアプリケーションは、YAML形式でエクスポートできます。そのため、他のユーザーでも簡単にアプリケーションを動かすことが可能です。 app: description: '' icon: 🤖 icon_background: '#FFEAD5' mode: advanced-chat name: チャットアプリ use_icon_as_answer_icon: false kind: app version: 0.1.2 workflow: conversation_variables: [] environment_variables: [] features: file_upload: image: enabled: false number_limits: 3 transfer_methods: - local_file - remote_url opening_statement: '' retriever_resource: enabled: false sensitive_word_avoidance: enabled: false speech_to_text: enabled: false suggested_questions: [] suggested_questions_after_answer: enabled: false text_to_speech: enabled: false language: '' voice: '' graph: edges: - data: sourceType: llm targetType: answer id: llm-answer source: llm sourceHandle: source target: answer targetHandle: target type: custom - data: isInIteration: false sourceType: start targetType: if-else id: 1744250148284-source-1744251195990-target selected: false source: '1744250148284' sourceHandle: source target: '1744251195990' targetHandle: target type: custom zIndex: 0 - data: isInIteration: false sourceType: if-else targetType: knowledge-retrieval id: 1744251195990-true-1744251325785-target source: '1744251195990' sourceHandle: 'true' target: '1744251325785' targetHandle: target type: custom zIndex: 0 - data: isInIteration: false sourceType: if-else targetType: llm id: 1744251195990-false-llm-target selected: false source: '1744251195990' sourceHandle: 'false' target: llm targetHandle: target type: custom zIndex: 0 - data: isInIteration: false sourceType: knowledge-retrieval targetType: llm id: 1744251325785-source-llm-target source: '1744251325785' sourceHandle: source target: llm targetHandle: target type: custom zIndex: 0 nodes: - data: desc: '' selected: false title: 開始 type: start variables: - label: RAGオン/オフ max_length: 48 options: - 'ON' - 'OFF' required: true type: select variable: RAG height: 89 id: '1744250148284' position: x: -78.33688053024684 y: 158.40698792460137 positionAbsolute: x: -78.33688053024684 y: 158.40698792460137 selected: false sourcePosition: right targetPosition: left type: custom width: 244 - data: context: enabled: true variable_selector: - '1744251325785' - result desc: '' memory: role_prefix: assistant: '' user: '' window: enabled: false size: 10 model: completion_params: temperature: 0.7 mode: chat name: anthropic.claude-3-5-sonnet-20240620-v1:0 provider: bedrock prompt_template: - id: 75ef1bf4-b63b-4112-ac19-863de25d714f role: system text: '{{#context#}}' selected: false title: LLM type: llm variables: [] vision: configs: detail: high enabled: true height: 97 id: llm position: x: 1033.7579811930557 y: 240.61385193672766 positionAbsolute: x: 1033.7579811930557 y: 240.61385193672766 selected: false sourcePosition: right targetPosition: left type: custom width: 244 - data: answer: '{{#llm.text#}}' desc: '' selected: false title: 回答 type: answer variables: [] height: 106 id: answer position: x: 1417.5860697804653 y: 240.61385193672766 positionAbsolute: x: 1417.5860697804653 y: 240.61385193672766 selected: false sourcePosition: right targetPosition: left type: custom width: 244 - data: cases: - case_id: 'true' conditions: - comparison_operator: contains id: f456ee9b-076f-42d3-b923-d5e6bd671e45 value: 'ON' varType: string variable_selector: - '1744250148284' - RAG id: 'true' logical_operator: and desc: '' selected: false title: IF/ELSE type: if-else height: 125 id: '1744251195990' position: x: 236.2764581017642 y: 158.40698792460137 positionAbsolute: x: 236.2764581017642 y: 158.40698792460137 selected: false sourcePosition: right targetPosition: left type: custom width: 244 - data: dataset_ids: - cf3656ef-4763-4a7f-be8d-d26c5e5e58ca desc: '' multiple_retrieval_config: reranking_enable: true reranking_mode: weighted_score top_k: 4 weights: keyword_setting: keyword_weight: 0.3 vector_setting: embedding_model_name: amazon.titan-embed-text-v1 embedding_provider_name: bedrock vector_weight: 0.7 query_variable_selector: - '1744250148284' - sys.query retrieval_mode: multiple selected: true title: 知識取得 type: knowledge-retrieval height: 91 id: '1744251325785' position: x: 601.5046934164834 y: 127.42604915556694 positionAbsolute: x: 601.5046934164834 y: 127.42604915556694 selected: true sourcePosition: right targetPosition: left type: custom width: 244 viewport: x: 97.03150392645694 y: 67.62661575788061 zoom: 0.5987393523094646  完成したチャットアプリケーション 完成したアプリケーションは、以下のような形です。 指定したIPアドレス範囲であれば、URLを公開することで、誰でもアクセスできるようになります。 RAG OFFでの挙動 まずは、RAG OFFの場合の挙動を確認してみます、 「SCSKとMLBはどんな関係がありますか？」と入力してみます。 本LLMでは、SCSKとMLBの契約に関する情報は未学習のため”直接的な関係はありません”という回答が生成されています。 RAG ONでの挙動 次に、RAGをONにしてみます。 先程と同様の質問をしてみます。 きちんと、事前に読み込ませたプレスリリースを基に”SCSKとMLBが2年間のパートナーを締結した”旨が回答されましたね。 Difyプラットフォームの社内導入結果 事業部門からコーポレート部門まで幅広い従業員が生成AIアプリケーションを自らの手で構築できるようになり、部署内での業務効率化やナレッジ活用が向上しました。新入社員でも、AIに関する情報収集アプリケーションや商材検索アプリケーション等短期間で業務に役立つAIツールを開発できるようになったことが特筆すべき点です。 今後もAIを活用した業務改革や人材育成を組織レベルで推進していきます。 InfoWeaveについて 弊社では、AWSアカウント上でエンタープライズのセキュリティ要件を満たしたRAGソリューション（InfoWeave）を展開しております。CloudFormationテンプレートで簡単にデプロイでき、エンタープライズシステムの連携も可能です。ご興味がある方はいつでもご相談くださいませ（メールアドレス：cbdc-all@scsk.jp）。 お問い合わせ｜企業のDX戦略を加速するハイブリッドクラウドソリューション 生成AI RAGソリューション InfoWeave｜SCSK株式会社 生成AI RAGソリューション（InfoWeave（インフォウィーヴ））は、S-Cred⁺ ※ の生成AIオプションサービスです。 www.scsk.jp かんたんRAG環境構築 S-Cred+ InfoWeaveをリリースしました SCSKでは、生成AIがより高精度の回答を出力できるRAG環境を、お客様AWSアカウントに構築できるテンプレートを提供する S-Cred+ InfoWeaveオプションを5月より提供開始しました。サービスの特徴とユースケースなどについて解説します。 blog.usize-tech.com 2024.07.08 最後に いかがだったでしょうか。 本記事では、DifyをAWSでホスティングする方法とRAGアプリケーションの開発手法を解説しました。 これを機に、皆さんの社内や個人でも、AWS上でDifyをセルフホスティングして、生成AIアプリケーション開発を始めてみてはいかがでしょうか。 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥

こんにちは、SCSK株式会社の伊藤です。 今年も、延べ 40,000 人以上が参加する、日本最大の “AWS を学ぶイベント” AWS Summit Japan 2025 が  6月 25 日（水） 、 26日（木） の二日間に渡り 幕張メッセ にて開催されます。 AWS Summit Japan 2025では、基調講演や160を超えるセッション、270を超えるEXPOコンテンツが用意されており、クラウド技術の最前線に触れる絶好の機会です。 SCSKはプラチナスポンサー として、パートナーセッションでの事例紹介とブース(013P)の出展を行います！ すでに満席のセッションもございますので、お早めにご登録ください ↓↓ SCSKセッションのご紹介 パートナーセッション（セッションID：AP-26）では、「 AIで振り込め詐欺を防止しろ!四国銀行の6ヶ月の挑戦 」というテーマで、 四国銀行様と当社メンバーの取り組みを事例に基づきご紹介いたします。 開始日時：2025/6/26（木）13:30～14:00 登壇者：株式会社四国銀行 システム部 厚海 悠貴様 　　　　 SCSK株式会社 ITインフラサービス事業グループ クラウドサービス事業本部 クラウドサービス第二部　貝塚 広行 概要 社会問題となっている「振り込め詐欺」の急増に対し、金融機関では迅速な対策が求められています。高知に拠点を構える四国銀行は、SCSKが提供するAWS内製化支援サービス「テクニカルエスコート」を活用しAWS上で独自の振り込め詐欺防止システムの構築を進めています。本セッションでは四国銀行の担当者と共に、AWSのAIサービスを活用した振り込め詐欺防止システムの仕組みとその検証結果についてご紹介いたします。AWS初心者であった四国銀行がどのように開発に成功したのか、その挑戦のプロセスを交えてご紹介します。 本セッションでは、 AWSのAIサービスを使用した開発、構築の知見を共有し、参加者の皆様の課題解決の糸口を提供できればと思います。 ぜひセッションをご登録してお待ちください！ では皆様、 AWS Summit Japan 2025で是非お会いしましょう。 当日はSCSKセッションならびに展示ブースへの来場を心よりお待ちしております！

こんにちは。SCSKの上田です。 Zabbixには、 サポート期間 があることをご存知でしょうか？ Zabbixを安心して利用し続けるためには、サポート期間を把握し、適切なバージョンアップを行うことが必要不可欠です。 今回は、 Zabbixのサポート、そしてバージョンアップの重要性 について書いていきます。 サポートの種類について Zabbixのサポートには、 ３種類のサポート があります。リリース後の期間に応じて享受できるサポートの種類が確定します。 フルサポート 期間：バージョンのリリースから3年間 対応内容： インストール方法、使用方法、設定方法に関するお問い合わせ 問題の原因調査・分析 すべてのレベルのバグ修正 機能改善要望への対応 リミテッドサポート 期間：フルサポート終了から2年間 対応内容： インストール方法、使用方法、設定方法に関するお問い合わせ 問題の原因調査・分析 深刻度の高いバグの修正 セキュリティフィックス 延長サポート 期間：リミテッドサポート終了から2年間 対応内容： インストール方法、使用方法、設定方法に関するお問い合わせ 問題の原因調査・分析 フルサポートが終了すると、 深刻度の高いバグしか修正されなくなります 。また、リミテッドサポ―トが終了すると、 セキュリティフィックスを含むアップデートも行われなくなります 。 そのため、 サポート期間が終了する前に、新しいバージョンにバージョンアップすることが重要 となってきます。 なお、対応内容に記載のお問い合わせや問題の調査に関しては、 有償の Enterpriseサポート に加入する必要があります 。弊社でもEnterpriseサポートを取り扱っておりますので、詳細は以下のページを御参照ください。 （※延長サポートで加入される方は、事前にご相談ください） サービス内容｜SCSK Plus サポート for Zabbix Zabbix社の認定パートナーとして、さまざまなシステム環境でZabbixを構築・運用してきたSCSKでは、そのノウハウをフルに活かして、お客様のZabbix活用をトータルでサポートしています。 www.scsk.jp 各バージョンのサポート期間 各バージョンのサポート期間をまとめました。（サポートが継続されているLTSバージョンのみ） バージョン リリース フルサポート終了 リミテッドサポート終了 延長サポート終了 Zabbix 7.0 LTS 2024/6 2027/6 2029/6 2031/6 Zabbix 6.0 LTS 2022/2 2025/2 2027/2 2029/2 Zabbix 5.0 LTS 2020/5 2023/5 2025/5 2027/5 Zabbix 4.0 LTS 2018/10 2021/10 2023/10 2025/10 直近では、 2025年5月末にZabbix 5.0のリミテッドサポートが終了 し、 2025年10月末にZabbix4.0の延長サポートが終了 します。 そのため、 2025年6月からZabbix 5.0のセキュリティフィックスを含む全てのアップデートが行われなくなり、 2025年11月からZabbix4.0に関するお問い合わせができなくなります。 現在上記のバージョンをご利用中の方は、ご注意ください。 現在ご利用中のZabbixのバージョンは、以下のように確認可能です。 CLIの場合 以下のコマンドでバージョンが出力されます。 # zabbix_server -V GUIの場合 Web管理コンソールの最下部にバージョンが表示されます。 バージョンアップの重要性 昨年Zabbixでは、 CVSSスコアがCriticalの脆弱性が3件 発表されました。 【緊急】Zabbix の脆弱性情報 CVE-2024-22116 (CVSS 9.9) 2024年8月9日（現地時間）にZabbix社は、監視ソリューション「Zabbix」に深刻な脆弱性があると公表いたしました。 この脆弱性が悪用された場合は、システム全体が危険にさらされる可能性があるため、緊急のアップデートが推奨されております。 blog.usize-tech.com 2024.08.21 【緊急】Zabbix の脆弱性情報 CVE-2024-42327 (CVSS 9.9) Zabbixに関する深刻な脆弱性について、詳細を説明します。 blog.usize-tech.com 2024.11.29 【緊急】Zabbix の脆弱性情報 CVE-2024-42330 (CVSS 9.1) Zabbixに関する深刻な脆弱性（CVE-2024-42330）が発表されました。本記事で詳細と対処方法について説明します。 blog.usize-tech.com 2025.02.03 リミテッドサポートが終了すると、このような緊急性の高い脆弱性が見つかってもマイナーバージョンがリリースされず、対応がメジャーバージョンアップしかなくなってしまいます。 Zabbixのメジャーバージョンアップは、バージョン間によってはトリガー条件式が変わっていたり、マクロを書き換える必要があったりと、 考慮すべきポイントが多い です。 そのため、 余裕を持ったバージョンアップの計画 をオススメします。 最後に 今回は、Zabbixのサポートについてまとめました。 Zabbix 4.0とZabbix 5.0に関してはもうすぐサポートが終了しますので、お早めにバージョンアップをご検討ください。 弊社では、バージョンアップの支援を行っております。 バージョンアップのやり方が不明な方や、自社だけでのバージョンアップに不安のある方は、是非弊社までお声がけください！ ↓お問い合わせはこちらから↓ お問い合わせ 製品・サービスについて 入力 ｜ SCSK株式会社 SCSK株式会社 製品・サービスについてご意見・ご質問をお受けしております。 www.scsk.jp 最後まで読んでいただき、ありがとうございました。 弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。 ★Zabbixの基礎をまとめたeBookを公開しております！★ FAQ・お問い合わせ｜SCSK Plus サポート for Zabbix 導入をご検討される際、よくあるご質問と回答についてまとめております。 www.scsk.jp ★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アカウントを開設しました！★ x.com x.com

こんにちは、広野です。 Amazon CloudFront のアクセスログをパーティション分けして Amazon S3 に保存できるようになるアップグレードがありましたので、既存アプリの構成を変更しました。AWS CloudFormation でデプロイしているので、テンプレートベースで説明します。 作成した構成 以下のように、2つの Amazon CloudFront ディストリビューションのアクセスログを 1つの共用 Amazon S3 バケットに保存する構成です。バケットの中でフォルダ分け (パーティション分け) します。これができないと後々 Amazon Athena での検索が高負荷になってしまいます。 AWS マネジメントコンソールからの設定は簡単で、以下公式ドキュメントの通りです。Amazon CloudFront ディストリビューションのロギング設定画面からできます。従来のロギング設定はコンソール画面上でも Legacy と表示されているので、間違えないかと思います。 標準ログ記録 (v2) を設定する - Amazon CloudFront Amazon CloudFront の標準ログ記録を有効にし、指定した配信先にアクセスログを送信できます。 docs.aws.amazon.com AWS CloudFormation によるデプロイ AWS CloudFormation でデプロイするときは、Amazon CloudFront のリソースとして定義するのではなく、Amazon CloudWatch Logs の設定として定義します。これは、上記ドキュメントにも書いてありましたが Amazon CloudWatch を内部的に使用しているからです。 なお、Amazon CloudFront は本体がバージニア北部リージョンにあるため、AWS CloudFormation でスタックを作成するときにはバージニア北部でテンプレートを流す必要があります。 概念的には以下の図のようになります。 今回の設計では、ログ配信先は共用の Amazon S3 バケットにしたかったので、その定義は 1つになります。 ログソースは Amazon CloudFront ディストリビューションが 2つありますので、定義は 2つになります。ログソースとログ配信先を紐づける定義が必要になるので、やはりそれぞれに必要になります。 AWS CloudFormation テンプレート 実際の例は以下になります。前提として、Amazon CloudFront ディストリビューションは完成していて、ID を知っている状況です。 細かい説明はテンプレート内にコメントします。 AWSTemplateFormatVersion: 2010-09-09 Description: The CloudFormation template that creates CloudFront access logging configurations. You had better delete the stack and create it again if you update this configurations. # ------------------------------------------------------------# # Input Parameters # ------------------------------------------------------------# Parameters: SubName: Type: String Description: System sub name of example. (e.g. prod or test) Default: test MaxLength: 10 MinLength: 1 # 1つ目のCloudFrontのIDをパラメータにしています。 CloudFrontDistributionIdImg: Type: String Description: The CloudFront distribution id for img. Default: XXXXXXXXXXXXX MaxLength: 15 MinLength: 12 # 2つ目のCloudFrontのIDをパラメータにしています。 CloudFrontDistributionIdAppsync: Type: String Description: The CloudFront distribution id for appsync. Default: XXXXXXXXXXXXX MaxLength: 15 MinLength: 12 Resources: # ------------------------------------------------------------# # CloudWatch Logs (for CloudFront) # ------------------------------------------------------------# # ログ配信先の定義です。1つのS3バケットを共用します。フォルダのプレフィックスに cloudfrontAccesslog を設定しています。 # 出力フォーマットは JSON にしていますが、実際には GZIP 圧縮されます。 LogsDeliveryDestination: Type: AWS::Logs::DeliveryDestination Properties: Name: !Sub s3-example-${SubName}-logs DestinationResourceArn: !Sub "arn:aws:s3:::example-${SubName}-logs/cloudfrontAccesslog" OutputFormat: json Tags: - Key: Cost Value: !Sub example-${SubName} # 1つ目のログソース定義です。 LogsDeliverySourceImg: Type: AWS::Logs::DeliverySource Properties: Name: !Sub example-${SubName}-cloudfront-img ResourceArn: !Sub "arn:aws:cloudfront::${AWS::AccountId}:distribution/${CloudFrontDistributionIdImg}" LogType: ACCESS_LOGS Tags: - Key: Cost Value: !Sub example-${SubName} # 1つ目のログソース、ログ配信先の紐づけ定義です。 LogsDeliveryImg: Type: AWS::Logs::Delivery Properties: DeliverySourceName: !Sub example-${SubName}-cloudfront-img DeliveryDestinationArn: !GetAtt LogsDeliveryDestination.Arn # 記録する項目はデフォルトです。 RecordFields: - timestamp - DistributionId - date - time - x-edge-location - sc-bytes - c-ip - cs-method - cs(Host) - cs-uri-stem - sc-status - cs(Referer) - cs(User-Agent) - cs-uri-query - cs(Cookie) - x-edge-result-type - x-edge-request-id - x-host-header - cs-protocol - cs-bytes - time-taken - x-forwarded-for - ssl-protocol - ssl-cipher - x-edge-response-result-type - cs-protocol-version - fle-status - fle-encrypted-fields - c-port - time-to-first-byte - x-edge-detailed-result-type - sc-content-type - sc-content-len - sc-range-start - sc-range-end - timestamp(ms) - origin-fbl - origin-lbl - asn # ここで年月日と時間でパーティション分けしています。 S3SuffixPath: img/{yyyy}/{MM}/{dd}/{HH} S3EnableHiveCompatiblePath: false Tags: - Key: Cost Value: !Sub example-${SubName} DependsOn: - LogsDeliveryDestination - LogsDeliverySourceImg # 2つ目のログソース定義です。 LogsDeliverySourceAppsync: Type: AWS::Logs::DeliverySource Properties: Name: !Sub example-${SubName}-cloudfront-appsync ResourceArn: !Sub "arn:aws:cloudfront::${AWS::AccountId}:distribution/${CloudFrontDistributionIdAppsync}" LogType: ACCESS_LOGS Tags: - Key: Cost Value: !Sub example-${SubName} # 2つ目のログソース、ログ配信先定義です。基本的な設定は1つ目と全く同じです。 LogsDeliveryAppsync: Type: AWS::Logs::Delivery Properties: DeliverySourceName: !Sub example-${SubName}-cloudfront-appsync DeliveryDestinationArn: !GetAtt LogsDeliveryDestination.Arn RecordFields: - timestamp - DistributionId - date - time - x-edge-location - sc-bytes - c-ip - cs-method - cs(Host) - cs-uri-stem - sc-status - cs(Referer) - cs(User-Agent) - cs-uri-query - cs(Cookie) - x-edge-result-type - x-edge-request-id - x-host-header - cs-protocol - cs-bytes - time-taken - x-forwarded-for - ssl-protocol - ssl-cipher - x-edge-response-result-type - cs-protocol-version - fle-status - fle-encrypted-fields - c-port - time-to-first-byte - x-edge-detailed-result-type - sc-content-type - sc-content-len - sc-range-start - sc-range-end - timestamp(ms) - origin-fbl - origin-lbl - asn S3SuffixPath: appsync/{yyyy}/{MM}/{dd}/{HH} S3EnableHiveCompatiblePath: false Tags: - Key: Cost Value: !Sub example-${SubName} # 1つ目のロギング設定が完了していないのに2つ目をデプロイしようとするとエラーになります。 # そのため DependsOn を使用して1つ目の設定が完成後に2つ目をデプロイするよう制御しています。 DependsOn: - LogsDeliverySourceAppsync - LogsDeliveryImg   また、本件の構成ではログ配信先 Amazon S3 バケットに以下のバケットポリシーが必要です。 S3BucketLogs: Type: AWS::S3::Bucket Properties: BucketName: !Sub example-${SubName}-logs OwnershipControls: Rules: - ObjectOwnership: BucketOwnerEnforced PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true Tags: - Key: Cost Value: !Sub example-${SubName} S3BucketPolicyLogs: Type: AWS::S3::BucketPolicy Properties: Bucket: !Ref S3BucketLogs PolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Action: s3:PutObject Principal: Service: delivery.logs.amazonaws.com Resource: !Sub "${S3BucketLogs.Arn}/*" Condition: StringEquals: aws:SourceAccount: !Ref AWS::AccountId s3:x-amz-acl: bucket-owner-full-control ArnLike: aws:SourceArn: !Sub "arn:aws:logs:us-east-1:${AWS::AccountId}:delivery-source:example-${SubName}-*" 注意事項 繰り返しになりますが、AWS CloudFormation テンプレートはバージニア北部リージョン (us-east-1) で実行します。 今回使用している AWS CloudFormation のログ配信先リソース定義 AWS::Logs::DeliveryDestination は、単純に変更しようとすると Name を変更しなさい、というエラーが発生します。なので変更をかける都度、Name を動的に変更したいのですが AWS CloudFormation テンプレートの記述のみでは実現できないので、もし変更する際には一度スタックを削除する方が確実です。カスタムリソースで AWS Lambda 関数と組み合わせたり、CI/CD ツールの機能や CDK とかであれば実現は可能と考えます。 また、ログソースと配信先を紐づける定義 AWS::Logs::Delivery は同じ種類のログ配信 (S3 なら S3、Firehose なら Firehose) を 1つのログソースに複数設定できないので、AWS CloudFormation で変更をかけようとするとこれまたエラーになります。上述、一度スタックを削除した方が確実と申し上げたのはそのような理由もあります。これらの課題は AWS さんによる今後の改善を期待します。 従来、Amazon CloudFront から Amazon S3 にロギングするときには、対象の Amazon S3 バケットに ACL が必要でした。新しいロギングではそれが不要になり、代わりにバケットポリシーが必要になっています。既存のロギング用バケットに AWS CloudFormation による変更をかける際には、先に ACL を手動削除しないとエラーになることがあります。 まとめ いかがでしたでしょうか？ なんとなく、今後 AWS リソースのロギング設定は今回のように Amazon CloudWatch Logs 側での設定に集約されていくのかな？と感じました。実際、イベントトリガーのアクションについては Amazon EventBridge が主流になっていますし、ロギングもそうなるのかな、という想像です。 本記事が皆様のお役に立てれば幸いです。

こんにちは、ひるたんぬです。 GWも終わり、しばらくは祝日のない日が続きますね。 今年のGWはいわゆる「飛び石連休」でした。カレンダーを眺めているとふと気になったのですが、なぜ、日曜日の祝日は振替休日となるのに、土曜日の祝日は振り替えてくれないのでしょうか…（今回のGWですと、5月3日の憲法記念日ですね。） とある日の衆議院議会でも取り上げられていました。（質問答弁内容は こちらから ） 関連法令を調べてみると、「国民の祝日に関する法律」にて以下のように定められていました。 「国民の祝日」が 日曜日に当たるとき は、その日後においてその日に最も近い「国民の祝日」でない日を休日とする。 引用：e-gov 法令検索「 国民の祝日に関する法律（昭和二十三年法律第百七十八号） 」 この法律が改正され、土曜日・日曜日に当たるとき…と変わる日を祈っております。 なお、弊社では土曜日が祝日に当たるときは、翌週月曜日を「一斉有給休暇取得日」と定めております。 参考： SCSK株式会社 「弊社の一斉有給休暇取得日のお知らせ（2025年度）」 さて、今回は少し局所的な内容についてご紹介したいと思います。 困ったこと Amazon WorkSpacesにてWindows OSを利用していたところ、キーボードが英字配列のキーボードとして認識されていました。 今回の構成 今回のWorkSpaces周りの設定は以下のようになっています。 後述しますが、今回は「ローカル管理者の設定」がミソでした。 ディレクトリ：Simple AD メンテナンスモード：無効 ローカル管理者の設定：無効 アクセスコントロール：Windowsの信頼されたデバイスのみ WorkSpaces タイプ：Personal バンドル：Standard with Windows 10 (Server 2022 based) プロトコル：DCV （WSP） 言語：Japanese 実行モード：常にオン（自動停止も同様でした） 接続方法 Amazon WorkSpacesクライアントアプリケーション バージョン：5.26.2.5308 接続元OS：Windows 11 23H2 やってみたこと 公式ドキュメントの確認 まずは、公式の回答を確認します。 WorkSpaces の言語とキーボードの設定 - Amazon WorkSpaces Amazon WorkSpaces で言語固有のキーボードを使用する方法を説明します。 docs.aws.amazon.com 上記に則り設定画面を参照しますが、肝心なキーボードレイアウトの変更画面が表示されません。 他の多くのサイトも同様の解決策を提示していたので、これは困ったものです。。 他のサイトを確認 他の解決策を確認したところ、デバイスマネージャーからキーボードのドライバーを変更している事例がありました。 Amazon WorkSpaces Windows 10 でキー配列を 106( 日本語 ) に設定する みなさん、WorkSpaces 使ってますか？ 私はあまり使わないのですが、最近、案件ベースで需要がでてきています。 オンプレでも EC2 上でもいいのですが、既存の AD に参加して使うケースが増えてます。 AD Co ... cpu100per.aminchu.net こちらも試してみましたが、私の環境では再起動すると元のドライバーに戻ってしまい、うまく設定ができませんでした。 また、設定作業を進めるうえで警告メッセージが表示されるのは少しいやな感じがしたため、この策の深堀りはやめました。 設定の見直し ここで、一度WorkSpacesの構成に立ち返ってみます。 今回は使用者に過大な操作権限を付与したくないため、「ローカル管理者」は無効、つまり接続先のユーザは「標準ユーザー」ということになります。 そのため、「標準ユーザーではキーボードレイアウトの変更ができない？」という仮説を立てて調査をしました。 すると、この仮説が正しいであろうことが判明しました。 Redirecting answers.microsoft.com 英語キーボードを日本語環境で使いこなすために必須の設定とは？ 事例詳細｜つなweB つなweb運営担当者が更新する詳細ページです。 tsunaweb.book.mynavi.jp そのため、この説を立証するべく、実際に操作してみます。 解決策 まずは、通常通りWorkSpacesに接続します。 このときのユーザーは先述の通り、管理者権限を持たないユーザーです。 次に、管理者アカウントへの切り替えを実行します。 WorkSpacesのクライアントアプリケーションから「表示」→「Ctrl + Alt + Delete で送信」をクリックします。 ユーザーの切り替えをクリックします。 もう一度「Ctrl + Alt + Delete で送信」をした後にサインイン画面が出るので、左下「他のユーザー」をクリックします。 ユーザー名とパスワードを入力します。 パスワードはディレクトリ管理者のパスワードです。 ユーザーの前に、ドメイン名を必ず入力し、ドメイン管理者としてサインインをしてください。 入力をしないと、ローカル管理者として認識されます。 ここまでできたら、後は公式ドキュメントに従い、キーボードレイアウト変更の画面まで進みます。 すると… レイアウト変更できるようになりました！🎉 後はレイアウトを変更し、WorkSpacesを再起動すれば設定が反映されます。 まとめと小言 今回は「ローカル管理者」が無効となっているWorkSpacesの環境において、アカウントの切り替えを実行することによりキーボードレイアウトを変更できる手順をご紹介しました。 バンドルでJapaneseを選んでいるので、最初から日本語キーボードになっていると嬉しいのですが… もしくは、私が英語配列のキーボードを使用すれば万事解決ですかね！

こんにちは。SCSKの坂木です。 今回はZabbixのcount関数を使った複雑な条件のログ監視を行う方法をご紹介します。 ログ監視は、例えば「”ERROR”という文字列が含まれる」「イベントIDが”777″」などシンプルな条件なら簡単に作成できますよね。 しかし、 5 分間で5回”ERROR”という文字列が含まれる といった条件はパッと作成できますか？ さらには、 5分間で 連続で 5回”ERROR”という文字列が含まれる といったように、「連続で」という条件がつくとさらに頭を悩ませるのではないでしょうか。 そこで今回は、このような条件式を作成できる count関数を用いたログ監視 について紹介していきます。   ログ監視 Linuxのログは、以下のアイテムキーで取得できます。 アイテムキー： log[監視するファイル名] 以下は、ログ監視のアイテム設定画像です。今回の場合、監視対象ファイルは/var/log/zabbix/testlogです。   複雑なログ監視のやり方 countを用いた監視方法① 監視対象ファイルにおいて、 評価期間のうちに〇回以上”検知文字列”が含まれる というトリガー条件式は以下の通りです。ちなみに、”検知文字列”では グローバル正規表現 は利用できないため、条件式に直接検知文字列を記載する必要があります。 障害の条件式： count([/ホスト名/アイテムキー],評価期間, ,”検知文字列”)>=〇   では、/var/log/zabbix/testlogにおいて、 5分間のうちに5回以上”ERROR”の文字列が含まれる といった条件式を考えてみます。 上記の式に当てはめて、作成してみましょう。 実際に/var/log/zabbix/testlogにログを書き込んでみます。 5分間のうちに、ERRORが5つ書き込まれているため、障害として検知しました。   countを用いた監視方法② 続いて、/var/log/zabbix/testlogにおいて、 5分間のうちに連続で5回以上”ERROR”の文字列が含まれる といった条件式を考えてみます。 まず、この 連続5回以上 という条件式は以下の通りです。 障害の条件式： count([/ホスト名/アイテムキー],#5, ,”文字列”)>=5 評価期間を、<数字> → #<数字>とすることで、時間 → 回数へ変更できます。   先ほどの条件を組み合わせると、こちらのようにトリガーを設定できます。andを使った条件式について詳しく知りたい方は こちら 。   実際に/var/log/zabbix/testlogにログを書き込んでみます。5分以内に連続せず5回以上”ERROR”を書き込むパターンと、5分以内に連続して5回以上”ERROR”を書き込むパターンを検証します。 5分以内に連続せず5回以上”ERROR”を書き込むパターン 5分以内に、”ERROR”を6個ファイルに書き込んでみました。結果、5回連続という条件は満たしていないため、障害として検知しませんでした。 5分以内に連続して5回以上”ERROR”を書き込むパターン 5分以内に、”ERROR”を連続して5個ファイルに書き込みました。結果、両方の条件を満たしているため障害として検知しました。   まとめ 本ブログでは、Zabbixの count関数を使った複雑な条件のログ監視 について紹介しました。 countを用いることで、ログ監視において特定の文字列を複数回検知したときに障害として検知できることを紹介しました。 この記事を参考にぜひ試してみてください！   Zabbixで複雑なログ監視を実装する方法シリーズファンの方へ 以下のブログでは、and/orを使った複合条件や除外条件について詳しく説明しています。 Zabbixで複雑なログ監視を実装する方法 ZabbixでLinux、Windowsのログ監視を行う方法と、複雑な条件のログ監視を行うときの条件式の書き方をご紹介します。 blog.usize-tech.com 2024.08.26

こんにちは。角田です。 先日、SASEについて初心者向けの解説記事を投稿しました。 【SASE簡単解説】SASEとは？ 初心者が1から解説 「近年バズワードとして注目されていることは知っているが、調べてみてもよく分からない。」これを機にSASEを理解したい、という方に向けて、超初心者向けの「SASEとは？」を1から丁寧に説明していきたいと思います。 blog.usize-tech.com 2025.03.24 今回はその続編として、初心者向け「SASEとは？」の第2弾をお届けします。 前回はSASEの概要やメリットについて触れましたが、今回は「いざSASEを導入しよう」となった際に気になるポイントについて、以下2つのテーマでご説明します。 SASE導入における懸念点・ハードル SASE導入を検討しやすいタイミング   SASE導入における懸念点・ハードル SASE導入にあたっては、多くの企業様から以下のような懸念や質問をいただきます。 ① 結局、現行ネットワークより高額になるのでは？ ② ネットワークをクラウドに移行しても、可用性やセキュリティは問題ないの？ ③ オンプレミスではなくなると可視性やコントロールが失われるのでは？ ④ 運用が変わるので使いこなせるか不安。学習コストもかかるのでは？ ここでは、それぞれの懸念に対して「実際のところはどうなの？」を丁寧に解説していきます。 ①結局、現行ネットワークより高額になるのでは？ コスト面は、多くの方が最初に気にされるポイントです。 よくあるご相談としては、 「今のネットワークから追加費用がかかるのでは？」 、 「クラウドは毎月(または毎年)の課金なので、長い目で見ると高額になるのでは？」 というものになります。 結論として、上記はどちらも誤解がありますし、むしろSASEを導入することで、 現行環境よりコストが削減できる 場合も数多くあります。 それぞれ、詳細を解説していきたいと思います。 「今のネットワークから追加費用がかかるのでは？」　に回答！ まず、SASEは現行ネットワークに追加導入するものではなく、 現行環境からリプレイスする(置き換わる)もの です。 SASEの費用は新たに発生しますが、その分、置き換わる既存機器やサービスの費用は削減できます。 つまり、基本的に「現行費用に加えて更にコストがかかってしまう」ことはありません。 SASE導入により削減可能な機器/サービスの例： 通信回線(専用線/閉域網)、通信機器(ルータ)、UTM、ファイアウォール、Proxy、VPN、 アンチマルウェアやIPS/IDS、CASBなどの各種セキュリティ製品   「クラウドは毎月/毎年コストの課金なので、長い目で見ると高額になるのでは？」　に回答！ 「クラウドサービスで毎月/毎年コストが発生する」ということ自体は、誤りではありません。 直感的には、一度購入すればその後支払いのないオンプレミスや買い切り型のほうがお得なイメージがあるかもしれません。 ただ、SASEは利用状況に応じて柔軟に帯域や機能を増減することが可能です。（使う分だけ都度契約・都度課金） つまり、一度購入すると保有し続けなければいけないオンプレミスと比べ、 コストの最適化 ができます。 また、SASEを導入すると、一般的に導入前と比較して ネットワーク/セキュリティの運用・保守にかかる負担は大幅に低減 されます。 ※例えば、オンプレミスのファイアウォールやVPN装置は頻繁に脆弱性が公表されるため、パッチ適応に相当の作業が必要となりますが、SASEではこのような作業が必要なくなります。 他にも、オンプレミス環境であれば発生する 機器リプレイス時の作業費は、SASEでは必要なくなります。 キャッシュとして見えないので分かりづらいですが、これらの人件費・運用/作業外注費(コスト)は削減できるということです。 コスト比較の際には、ぜひ オンプレミス製品の償却年数や運用・保守・リプレイス作業のコスト も加味し、整理していただければと思います。 オンプレミス/SASEにおけるコストのイメージ ※あくまでコスト形態を比較するためのイメージ図です。 補足：財務的な話になりますが、オンプレミスの場合は資産として計上される(固定資産税の対象となることもある)各種機器も、クラウド(SASE)では費用として計上できる(固定資産税を支払ったりする必要がない)ことも特徴です。 ② ネットワークをクラウドに移行しても、可用性やセキュリティは問題ないの？ こちらもコストと並んでよくいただく懸念点・ご質問となりますが、過度に心配する必要はありません。 まず、可用性についてですが、多くのSASEベンダはサービスレベル契約(SLA)が明示されています。 ※ファイブ・ナイン（99.999%）をSLAとしているSASEもあります。 SASEはインターネット回線を用いたサービスとなるため、その点はキャリア閉域網のほうが安心感があるかもしれませんが、 純粋な SASE(ベンダの持つWANバックボーン)の可用性は専用線と遜色ありません。 また、特に 日本はインターネット回線の品質が良く、切断もほとんありません。 可用性を重要視する場合は、インターネット回線を冗長化する構成も可能です。これにより閉域網と同等の可用性を実現できます。 セキュリティについても、クラウドの特性上「インターネットを使うので安全でない」と思われがちですが、これは誤解です。 SASEは 「インターネット回線を用いて、SASEベンダのセキュアなネットワーク網に接続する」仕組み となりますので、企業の通信がそのままインターネットに出てしまうことはありません。 また、SASEベンダが保持する各種データセンター・機器は厳重に管理・運用されているため、通常は自社での管理よりも安心です。 むしろ、各種セキュリティ機能を一元管理できるため、SASE導入は企業のセキュリティレベル向上に繋がります。 ③ オンプレミスではなくなると可視性やコントロールが失われるのでは？ 確かに、オンプレミス機器は自社にあり、目に見え、触れて確かめられる安心感があるため、クラウドに移行すると見えなくなる・制御できなくなる、という印象を持たれる方は多いです。 しかし、実際は逆です。 SASEではむしろ可視性とコントロールは向上します 。 SASEを導入すると、全ての通信がSASEを経由することとなり、より広範囲かつリアルタイムでの可視化・制御が可能になるためです。 オンプレでは見えにくかった部分（例：社外デバイスやクラウドサービスの利用状況など）も一元化し把握できるようになります。 例えばセキュリティインシデントが発生した際にも、複数機器のログを突き合わせて確認したり、機器ごとに対処する必要はありません。 ログはSASEで一元管理されており、ネットワーク設定変更などの対処も、SAESの中で完結することができるのです。 ※つまり、可視性とコントロールが向上しているということになります。 ④ 運用が変わるので使いこなせるか不安。学習コストもかかるのでは？ これまでオンプレミス中心だったネットワーク環境からSASEへと切り替わると、運用に大きな変化があるのは事実です。 そのため、「慣れない仕組みを使いこなせるか」という不安を感じる方も多くいらっしゃいます。 ですが、SASEはもともと「バラバラだったネットワーク・セキュリティ機器やサービスを統合する」ための仕組みです。 つまり 「新しくて難しくなる」というよりも「分散していたものが纏まり、管理しやすくなる」 と考えるほうが本質的です。 加えて、SASEは直感的なUIが多く、インフラ運用経験が浅い方でも扱いやすいよう設計されていますので、新たなメンバーが加入した際の教育や引き継ぎもとても簡単に行えます。 SASE導入により一時的な負荷や学習コストが発生するのは確かですが、 長期的には運用の負荷が軽減され、今より使いやすく、管理しやすい環境になるはずです。   SASE導入を検討しやすいタイミング 「SASEについて理解し、メリットを知り、不安要素も払拭された」というところで、次に「では、いつSASEを導入すればよいか？」という点も気になります。 SASEで現行よりコスト削減ができる場合も多いですし、スモールスタートも可能ではありますが、全社SASEとする場合は大きな投資にもなり得ます。 どのタイミングであればSASE導入を検討しやすいのか 、パターン別で以下のように分類してみました。それぞれ解説していきます。 No パターン 具体的な場面（例） ① ネットワークやセキュリティ機器の更改 ・WANの見直し、更改 ・VPN装置の見直し、機器の更改 ・Proxyサーバの見直し、サーバ機器の更改 ② 拠点の増設、グローバル展開 ・グローバル拠点展開/グローバルなネットワーク接続 ・企業買収(M&A) ③ クラウド化への適応 ・パブリッククラウドへのシステム移行(AWS、Azureなど) ・SaaSの急激な利用増 ④ その他のタイミング ・セキュリティインシデントへの対応、セキュリティの見直し ①ネットワークやセキュリティ機器の更改 冒頭で、SASEは既存機器のリプレース(置き換え)であると説明しました。 そのため、当たり前だと思われるかもしれませんが、 「機器の更新タイミング(EOLや契約更新など)」でSASEを導入するのが最も自然で予算化もしやすい です。 同様の機器を買い替える代わりにSASEを導入することで、無駄なく既存ネットワークの課題を解消する、というイメージとなります。 特に専用線やWANの更改タイミングは、全社SASE導入にもってこいのタイミングです。 一方で、昨今は リモートアクセス(VPNや仮想デスクトップなど)やProxyの切替にSASEを選択 され、徐々にWAN(拠点間通信)もSASEへ移行していく、という段階的な導入をされる企業が非常に増えています。 ※SSE(Secure Access Service Edge) → SASE(Secure Service Edge)という移行プロセスになります。 これは、在宅勤務やリモートワークの急速な普及に伴い発生した機器更改の機会を、SASE導入に繋げている好例です。 専用線やWANの更改だけに限らず、このタイミングの導入にもぜひ着目してみてください。 　SSE → SASE の移行イメージ　 ②拠点の増設、グローバル展開 事務所の新設や海外拠点の立ち上げ も、SASE導入の好機です。 特に海外拠点の場合は、個別の専用線調達、現地法令への対応、回線品質など、考慮事項が非常に多くなります。 SASEであれば、こうした煩雑さを最小限に抑え、短期間でセキュアなネットワークを展開できるため、手段として非常に有効です。 たとえば、まずは「新規拠点＋本社」だけSASEを導入し、そこから段階的に広げるというスモールスタートも可能です。 拠点新設、グローバル展開の予定がある場合は、ぜひスモールスタートも視野に入れてご検討ください。 ③クラウド化への適応 近年、開発スピードの向上、運用負荷の軽減、コスト最適化などを目的として、 システム全体のクラウド化 を推進する企業が非常に増えてきました。 自社がそのような方向性を目指している場合は、SASE導入のタイミングにも適しています。 サーバやアプリケーションのクラウド化に合わせて、ネットワーク・セキュリティもクラウド(SASE)化するというイメージです。 クラウドベースのアーキテクチャであるSASEは、IaaS、PaaS、SaaS問わずクラウドとの相性が良いです。 逆に、従来の境界型ネットワークの仕組みは、クラウド活用のボトルネックになることが多いです。 境界型ネットワークがクラウド活用のボトルネックとなる例： ・トラフィックがすべて本社/データセンターを経由するため、クラウド利用(インターネット利用)増加によりレスポンスが悪化する ・IaaS、SaaSごとのアクセス制御・ログ管理が煩雑化する ・拠点、本社/データセンター、クラウド間を個別最適で接続するため、運用が複雑化する SASEのメリットでもお話しましたが、SASEを導入すると上記のようなボトルネックは無くなります。 つまり、 SASEの導入はネットワークに関するボトルネックを排除し、企業のクラウド化を更に加速させる ことが出来るのです。 ④その他の導入タイミング 上記の通り、導入機会としてよくあるパターンを解説しましたが、もちろん、シンプルにSASEのメリットに魅力を感じ、導入に踏み切る企業様も数多くいらっしゃいます。 また、ネガティブな導入機会なので取り上げませんでしたが、「セキュリティインシデントが発生し、再発防止策を検討・実施する必要がある」という状況で早急にSASEを導入される方もいらっしゃいます。   「SASEには魅力を感じるけど自社でどう導入できるかまだイメージが湧かない」という方は、ぜひ一度弊社までご相談ください。 ご一緒にSASE導入の方向性について整理させていただければと思います。   おわりに いかがでしたでしょうか？ 今回は第1弾から少し踏み込んで、「SASE導入のよくある懸念点とその実態」、「SASE導入を検討しやすいタイミング」について説明しました。 詳しくない方にも伝わるよう、できるだけ分かりやすく解説したつもりですが、前回よりも踏み込んだ分、少し難しい内容もあったかもしれません。 イマイチ理解できなかった部分は、ぜひご自身でも深堀りしてみてください。 SCSKでは、長年に渡り SASEに関するセミナーを定期開催 しています。 直近では 2025/5/28(水) に、 世界初のSASEプラットフォームである「Cato(ケイト)クラウド」の簡単解説セミナー を開催します。 (オンラインセミナー) 世界初のSASE　Cato(ケイト)クラウドとは？　簡単解説セミナー 本セミナーでは、SASEの基本的な概念やその必要性・重要性から、世界初のSASEプラットフォームである「Cato（ケイト）クラウド」の特徴・強みについてご説明をいたします。また、セミナーの中では実際にCatoクラウドのデモをご覧いただけます... www.scsk.jp SASE全般について解説するパートもありますので、ご興味がある方は、ぜひご参加ください。 SASEはまだまだ知名度が低いですが、システム全体がどんどんクラウド化、モダナイゼーションしていく現代においては、とてもメリットがあるものだと感じています。 本記事が、皆さんのSASE導入や、SASEの更なる普及の一助になれば嬉しく思います。

初めまして。 SCSKの庄司です。 今回は、ServiceNowで「レコードのどの部分が、いつ、誰によって更新されたのか」の情報を取得・確認する方法を紹介していきます。 本記事は執筆時点（2025年5月）の情報になります。最新の内容は製品ドキュメントを参考にしてください。   事前準備：監査を有効化しよう ServiceNowは裏で「誰が何を変更したか」を記録する機能があります。 それが「監査ログ」です。 監査ログレコードは監査対象レコードの各フィールドの更新ごとに以下のような情報を自動で保存してくれます。 ・更新日時 ・対象フィールド名 ・更新前後の値 ・更新者　等 ただし最初からすべてのテーブルが監査対象になっているわけではありません。 まずは、特定のテーブルを監査対象に設定する方法を確認しましょう。 監査対象テーブルの設定手順 ①[システム定義]>[ディクショナリ]に移動 ②監査対象とするテーブルを検索し、列名=空欄、タイプ=コレクションのレコードを探す ③該当レコードの「監査」をTRUEに変更 テーブル丸ごとではなく特定の列のみを確認したい場合は、手順②でテーブルのレコードではなく対象としたい列のレコードを探し、「監査」をTRUEにしてください。 上記の手順を実施することでテーブルの監査ログ取得が可能となります。 ただし、手順実施以前のレコードの更新は取得できないことには注意が必要です。   監査ログを見てみよう さて、レコードの内容を更新して監査ログに更新内容がしっかりとキャッチされてるか見てみましょう。 今回はユーザー(sys_user)テーブルを監査対象としたので、ユーザーテーブルの任意のレコードの値(メール、部門、Web サービスへのアクセスのみ)を変更します。 変更前 変更後 監査ログの確認手順 ①Filter Navigatorに [sys_audit.list] を入力して監査ログテーブルにアクセス ②テーブル名やフィールド名、レコードのSys IDでフィルタをかけて検索します。 ③該当するレコードを探し、開きます。 監査ログレコードの各種列は以下内容を格納しています。 作成日時 監査対象レコードが更新された日時 テーブル名 監査対象レコードのテーブル フィールド名 監査対象レコードの更新されたフィールド ドキュメントキー 監査対象レコードのsysID ユーザー 監査対象レコードに更新をかけたユーザー 以前の値 監査対象レコードの該当フィールドの更新以前の値 新しい値 監査対象レコードの該当フィールドの更新後の値 試しにユーザーテーブルのたとえば「メール」フィールドを見てみると、先ほど更新した内容の更新日時、変更前後の値、更新者などがきちんと記録されています。 フォームコンテキストメニューから履歴を見る 一方で、わざわざ監査ログテーブルに遷移せずとも対象のレコードのフォーム画面から更新内容を確認する方法もありますので、そちらの方法も紹介します。 1.カレンダー形式で履歴を確認 ①対象のレコードのフォームを開く ②フォームコンテキストメニューから、[履歴]>[カレンダー]を選択 ③遷移先の「ユーザー履歴詳細」ページでは以下のような特徴があります。 ・レコードの更新履歴がカレンダー形式で表示されます ・各日付の更新者や更新内容がひと目で確認できます ・カレンダー上部に、フィールド名や更新前後の値も表示されます 2.リスト形式で履歴を確認 ①対象のレコードのフォームを開く ②フォームコンテキストメニューから、[履歴]>[リスト]を選択 ③遷移先の「レコード履歴」ページでは以下のような特徴があります。 ・フィールドごとのリスト形式で表示されます ・リスト上からはフィールド名や最終更新日時、最終更新者、更新前後の値などを確認することが可能です ・各レコードを押下することで、そのレコードに応じたフィールドの履歴を表示することができます    まとめ ServiceNowでは監査ログ機能を活用することで、「いつ・誰が・どこを・どう変更したのか」をしっかり追跡できます。 設定もシンプルなので、ぜひ日常の業務等に役立ててみてください。

こんにちは。SCSKの北川です。 今回はServiceNowの更新セット移送についてまとめてみました。 環境間の移送に不安がある方の参考になれば嬉しいです。 本記事は執筆時点（2025年4月）の情報です。最新の情報は製品ドキュメントを参考にしてください。 更新セットとは 更新セットは、カスタマイズや変更を他の環境へ移行するための機能です。 開発環境で行った変更を本番環境などへ反映させる際に使用されます。 更新セットの移送手順 移送対象の更新セットを選択 System Update Sets>Local Update Sets より移送したい更新セットを選択します。 自動で更新セットに記録されないテーブルがあるため、変更内容がすべてCustomer Updatesに含まれているか確認しましょう。 ステータスの更新 Stateを「In progress」から「Complete」に更新します。 XMLにエクスポート 保存後、Related Links[Export to XML]を押下します。 押下後、XMLファイルがダウンロードされていることを確認します。 移送先にインポート 移送先の環境にログインし、System Update Sets>Retrieved Update Sets より移送したい更新セットを選択します。 Related Links[Import Update Set from XML]を押下します。 エクスポートしたXMLファイルを選択し、[Upload]を押下します。 Retrieved Update Setsに移送対象の更新セットが追加されました。 プレビュー～コミット 更新セットを選択し、[Preview Update Set]を押下します。 Stateが「Previewed」に更新されました。 ※エラーの場合は対象レコードを確認・対応後に再度プレビューしてください。 [Commit Update Set]を押下します。 Stateが「Committed」に更新されました。 以上がServiceNowにおける更新セットの移送手順です。 コミット後は、移送内容が正しく反映されているかご確認ください。 まとめ 今回はServiceNowの更新セット移送についてご紹介しました。 初めて作業する方にも役立つ内容になっていれば嬉しいです。