どうもSCSK齋藤です。 EC2のバックアップを取得する際に、アプリケーション整合性の観点から、EC2を停止してからバックアップを取得するユースケースは発生すると考えられます。 Lambdaなどを使って、それらの手順を自動化することはできますが、今回はSystems Manager Automation Runbookを用いてノーコードでその仕組みを作成してみました。 大まかな流れ Systems Manager Automation Runbookで、以下の流れを自動化するランブックを作成します。 全EC2をディスクライブ 全EC2を停止 AWS BackupのAPIを使用してバックアップの作成 全EC2を起動 今回のバックアップはAWS Backupを用いたいと思います。   今回解説しない箇所 今回、下記の箇所は詳しく解説致しません。 AWS Backupで必要なIAMロールの作成方法 バックアップテスト用のEC2インスタンスの作成方法 AWS Backupで用いるIAMロールについては、本手順で使うIAMロール（backup_role）の画面キャプチャをあらかじめ記載しておきます。 また、EC2をバックアップさせるテスト対象のインスタンスについても、２台用意して検証してみます。   やってみた それでは、早速作成していきましょう！ Runbookの作成 SystemsManagerのコンソール画面の左のメニューから、「オートメーション」をクリックし、「Create Automation Runbook」をクリックします。   そうすると、以下のようなステートマシン作成画面に遷移します。   全EC2のディスクライブの処理の追加 まず、ディスクライブの処理を追加します。 先ほどのRunbook作成画面の左側の検索欄で、「AWS API」を選択します。 検索欄で、Describeinstancesと検索し、EC2のDescribeinstancesが出てきたら、Runbook内にドラッグ＆ドロップします。 そのまま、画面右側のDescribeInstancesのメニューの中で、出力タブに切り替えます。 どのような値を次の処理に渡すかを定義するため、下記の設定を行います。 設定内容の解説は下記になります。 項目 設定値 説明 名前 InstanceIds 任意の名前を入力できるので、どのような値を出力するかを定義します。 今回は、DescribeInstancesでインスタンスIDのリストを出力するので、このような名前とします。 セレクター $.Reservations..Instances..InstanceId AutoMationRunbookでは、裏でboto3が使われているので、boto3のドキュメントのレスポンス構造の中から、取得したい項目を指定します。 Responseの中身については、 ここ を参照してください。 タイプ StringList 今回はインスタンスIDの集合体を取得したいので、String型のリストとします。   全EC2を停止する処理の追加 ディスクライブしたインスタンスのリストを元に、全EC2の停止を行います。 左側の検索欄で、「アクション」を選択し、ChangeInstanceStateを検索します。 出てきたものを、ドラッグ＆ドロップします。 まず、名前をわかりやすく変更します。 次にインプットを編集します。 下記の値を設定します。 項目 設定値 説明 Instance IDs DescribeInstances.InstanceIds DescribeInstancesでリスト化したインスタンスIDたちが渡されます。 Desired state stopped 停止を行いたいため、stoppedとします。 全EC2をバックアップする処理を追加 ディスクライブしたインスタンスのリスト元に、全EC2のバックアップを行います。 今回は、Loop処理を追加し、その中でインスタンス１つ１つのバックアップ処理を含める形とします。   Loop処理の追加 左側の検索欄で、アクションを指定し、ループを選択します。そのまま、ドラッグ＆ドロップで、StopInstancesの下につけます。 ステップ名を自由に設定できるので、わかりやすく「BackupLoop」と名付けます。   次に、右側のメニューのインプットを設定します。 ループタイプを今回はFor eachに選択します。 その後、イテレーターを選択しますが、前段のDescribeInstancesで出力した、InstanceIdsを選択します。   バックアップ処理の追加 ループ処理の中に、バックアップの処理を追加していきます。 左側の検索欄で、「AWS API」を選択し、StartBackupJobを検索します。 出てきたものを、ドラッグ＆ドロップします。 次に、インプットタブを選択し、バックアップの条件を入力していきます。 設定内容の解説は下記になります。 項目 設定値 説明 BackupVaultName Default Backupの保存コンテナであるバックアップVaultの名前を設定します。 今回は、デフォルトでアカウントに用意されているDefaultという名前のバックアップVaultを使用します。 IamRoleArn arn:aws:iam::{account_id}:role/backup_role AWSBackupが用いるIAMロールのARNを指定します。 本ブログでは、冒頭で述べたIAMロールを使用しています。 ResourceArn arn:aws:ec2:{region}:{account_id}:instance/{{ BackupLoop.CurrentIteratorValue }} バックアップ対象のリソースのARNを指定します。 今回はループ処理の中でインスタンス１つずつ処理をしていくため、EC2のARNの型を用意しておき、末尾の部分を{{ BackupLoop.CurrentIteratorValue }}とすることで、ここにインスタンスIDが入り、EC2のARNが完成する形とします。 ※上記表の{region}と{account_id}は、それぞれご自身の環境のリージョン名とアカウントIDに置き換えてください。   全EC2を起動する処理を追加 左側の検索欄で、「アクション」を選択し、ChangeInstanceStateを検索します。 出てきたものを、ドラッグ＆ドロップします。 ついでに名前も、StartInstancesに変更します。 StartInstancesのメニューで、インプットタブを選択します。 項目 設定値 説明 Instance IDs DescribeInstances.InstanceIds DescribeInstancesでリスト化したインスタンスIDたちが渡されます。 Desired state running 起動したいため、runningとします。   保存と実行 最後に、名前を保存します。 画面左上のペンマークから編集を行い、お好きな名前で保存します。 次に、右上の「ランブックを作成」を押下します。 下記のような画面が出ますが、特に指定せず、画面下のExecuteを押下します。 そうすると、早速Runbookが走ります。   実行画面に遷移後、しばらく時間が経過した後確認すると、正しく実行されたのを確認することができました！ AWSBackupのコンソール画面に遷移し、保存したVaultを確認してみますと２つのバックアップが保存されているのを確認できました！   改めてのポイント 今回のRunbookで意識したポイントとして、AutomationRunbookに組み込まれているアクションである「ChangeInstanceState」を使ったところです。 EC2の停止と起動の際にaws:executeAwsApiのStopInstancesや、RunInstancesといったAPIを使う選択肢もありました。 しかし、これらのAPIは、一斉にEC2を停止や起動だけして状態の追跡をしません。 そのため、EC2が停止し切らない状態で次の状態に遷移（バックアップを取得）してしまうため、整合性を確保するという観点から望ましくありません。ですが、AutomationRunbookに組み込まれているアクションである「ChangeInstanceState」を使うことで、状態の追跡まで行ってくれます。 これを用いることで、インスタンスが停止し切った段階で次のワークフローに進んでくれるので、整合性を確保する観点から望ましいものとなります。   まとめ 今回は、インスタンスを停止してバックアップを行う自動化を、ノーコードにて実施してみました。 今回作ったRunbookを、EventBridgeルールで定期的にキックするようにすることで、毎日のバックアップなども容易になるかと思いますので、組み合わせてみるといいと思います。

こんにちは、ひるたんぬです。 10月も中頃を過ぎ、（個人的には）過ごしやすい季節となってきました。もう秋…ですかね？ ところで、、なぜ「〇〇の秋」という言葉だけ数多く存在するのでしょうか？ 「〇〇の春」「〇〇の夏」「〇〇の冬」…なくはないですが、圧倒的に秋に関する用語が多いように感じます。 これについて明確な文献は見つけられなかったのですが、例えば「スポーツの秋」は1964年の東京五輪、「読書の秋」は中国の漢詩に由来するもの、「食欲の秋」は食べ物の旬の多くが秋にあるという説があるそうです。 さて、今回は技術的なお話とは少し逸れますが、私がある時からずーーっと気になっていた用語についてまとめようと思います。 今回の記事を執筆するにあたり、多くの記事や周りの方への聞き取りを実施いたしました。 聞き取りに対して、多くの方から回答やご意見をいただきました。この場を借りて御礼申し上げます。 本記事は、それらの結果を自分なりに解釈しまとめたものですので、正確性に欠ける箇所がある場合があります。 きっかけは… 弊社では先月より新人が各部署に配属され、部署ごとの研修が始まりました。 私はAWS研修のサポーターとして、新人のサポートや質問対応をしていました。 新人ならではの新鮮な視点からの質問に対して、（ときにネットを駆使しながら）なんとか対応していた私ですが、ある新人さんから次のような質問を受けました。 すみません、 「フルマネージド」と「サーバレス」って何が違うんですか？？ …確かに。 今まで各サービスの特徴や説明を見る中で、これらの表現は何度も見てきましたが、この2つの用語の使い方に対して何ら疑問を抱く機会はありませんでした。また、後日調べてみてもなかなか腑に落ちることができなかったので、この機会にまとめようと思い記事にしました。 それぞれの違いについて まずはじめに、個人的に至った結論を以下にまとめます。 「フルマネージド」と「サーバレス」はベン図にまとめると下図の関係になります。 前提として 「フルマネージド」だけど「サーバレス」でないサービスは存在しますが、「サーバレス」だけど「フルマネージド」でないサービスは存在しません。 つまり、「フルマネージド」を極めた先が「サーバレス」という形式になるのかなと思います。 言葉だけだと分かりづらい点も多いと思いますので、実際のケースを一つ挙げてみたいと思います。 AWSにおけるデータベース利用 AWSでは「データベースを扱いたい！」と思った際には用途や予算、目的に応じて適切なサービスを選定できるよう多くのサービスが提供されています。今回はこのユースケースを元にまとめてみようと思います。 【参考】Amazon EC2 公式サイトには、EC2について以下のような説明がされています。 事実上すべてのワークロードに対応する安全でサイズ変更が可能なコンピューティングキャパシティ 引用：AWS「 Amazon EC2 」 つまり、どんなことにも使える汎用的なサービスだよ！ということですね。 EC2はいわゆるIaaSのサービスです。サーバ筐体そのものなどのハードウェア管理はAWS側が担っているものの、OSやアプリケーションといったソフトウェアのレイヤーは利用者が責任を持って管理をする必要性があります。また、どれくらいの性能のインスタンスを採用するか（インスタンスタイプを選択するか）も利用者側の判断に委ねられています。 EC2上に任意のデータベースエンジンを導入することでデータベースのサーバとして運用することは可能です。コスト面においてはサーバ利用料金のみのため安価で済む傾向がありますが、パッチ適用や暗号化、スケーリング、モニタリングなどを自身で設定する必要があるため、運用上のコストは大きくなってしまいます。 フルマネージドサービス：Amazon RDS フルマネージドサービスのデータベースサービスの一つとして、Amazon RDSが挙げられます。 Amazon Relational Database Service (Amazon RDS) は、クラウド内でデータベースを簡単に設定、運用、スケールできるようにする マネージドサービス を集めたものです。（後略） 引用：AWS「 Amazon RDS 」 – 機能の説明 ここでは「マネージドサービス」と記載があります。一方で、Amazon RDSの特徴ページの一項目には、次のような記載があります。 フルマネージド のクラウドデータベースサービスとして、データベースのニーズを簡単に管理 引用：AWS「 Amazon RDS – 特徴 」 – 「デプロイ環境の選択」 Easily manage your database needs as a fully managed cloud database service 引用：AWS「 Amazon RDS – Features 」 – 「Choice of deployment environments」 英語のページについても確認しましたが、同じように表記が混ざっていました。 以上のことから、本記事では「マネージドサービス」と「フルマネージドサービス」は実質的には同一の意味を指し示していることとします。 ここで、マネジメントコンソールからRDSのデータベースを作成してみましょう。 代表的な項目は「エンジンのタイプ」と「インスタンスサイズ」の選択です。 Amzon RDSではEC2と異なり、OSの選択がなくなっております。これはOSレイヤーについては利用者は意識することがなくなった（AWSに管理を委任する）ことを意味しています。また、データベースのエンジンについても選択することで初期セットアップが実施されるため、利用者による作業は不要になっています。 RDSの一部のパッチ適用（データベースエンジンのメジャーアップグレード）については、互換性が損なわれる可能性があるため、手動で対応する必要があります。 参考： AWS ドキュメント「DB インスタンスのエンジンバージョンのアップグレード」 一方で、インスタンスサイズの指定などはまだ残っており、その点についてはEC2と同様に「これくらいの規模のサーバで動いているんだなぁ。。」となんとなく分かるようにはなっています。 サーバレス：Aurora Serverless・DynamoDB Aurora ServerlessはAmazon RDSのデータベースエンジンの一つであるAmazon Auroraにおけるオンデマンド自動スケーリング設定です。 また、DynamoDBについては以下のような説明がされています。 あらゆる規模で一桁ミリ秒のパフォーマンスを実現する、 サーバーレス NoSQL フルマネージド データベース 引用：AWS「 Amazon DynamoDB 」 上記の説明より、DynamoDBは「サーバレス」であり、「フルマネージド」サービスであることが分かります。 これらのサーバレスサービスを設定する場合、インスタンスタイプはどのようになっているのでしょうか？ 先程のAmazon RDSでAmazon Auoraを選択し、Serverlessオプションを選択してみましょう。 選択できる項目が一つに減りましたね。 これにより、サーバレスなサービスではOSレイヤーの管理に加え、キャパシティ管理もAWS側に委任することができます。 おわりに 今回は少々技術的な内容とは逸れてしまいましたが、個人的に気になっていた「フルマネージドサービス」と「サーバレス」の違いについて、理解を深めることができました。新人の方には、改めてこの場を借りて御礼申し上げます。 一方で、「マネージドサービス」と「フルマネージドサービス」については、本記事では同一のものとして取り扱いましたが、表記が異なるものが存在するのも事実です。これらに厳密には違いがあるよ、ということが分かる有識者の方がいらっしゃいましたら是非ご教示ください。。 参考サイト 今回の記事を執筆するにあたり、私が参考にしたサイトや有識者の皆様から教えていただきました記事を以下に列挙いたします。技術的な内容ではない（業界用語である）ため、参考サイトはAWSに限定しておりません。 サーバーレスとフルマネージド: その違いとは？ | Google Cloud 公式ブログ cloud.google.com 【AWS】マネージドサービスとサーバーレスの違い - Qiita 【AWS】マネージドサービスとサーバーレスの違いクラウドコンピューティングが進化する中で、Amazon Web Services（AWS）はさまざまなサービスを提供しています。その中でも特に注目さ… qiita.com

こんにちは、SCSK株式会社の小寺崇仁です。 Zabbix7.0からZabbixプロキシの冗長構成が可能になりました。 制約事項等ありますので、検証しながら考察したいと思います。 プロキシの冗長構成について サーバ＋プロキシの構成 プロキシの冗長構成をする場合、Zabbixプロキシを2台構築します。 ZabbixのWeb管理画面にて「プロキシーグループ」を作成し、2台のプロキシを同じグループに設定します。 プロキシーグループに冗長構成のパラメータがあり、「フェイルオーバーの期間」が設定できます。デフォルトは「1m」となります。 ホスト設定でのプロキシの指定 ホストの設定画面にて、「プロキシーグループ」を選択します。 監視を担うZabbixプロキシサーバは自動的にZabbixサーバで割り振られます。 ホストの設定画面の「割り当てられたプロキシ」に割り当てられたプロキシサーバが表示されます。 ポイント ・Zabbixサーバがプロキシの状態を監視し、監視対象がどのプロキシサーバで監視を行うかコントロールしています。 ・Zabbixプロキシ間でハートビートするのような冗長構成ではありませんでした。 ・Zabbixプロキシの代表IP切り替えるような冗長構成ではありませんでした。 ・Zabbixプロキシ側で冗長構成を行うための設定はありませんでした。   監視対象の構成について 監視対象側での注意事項をまとめます。 シンプルチェック Ping監視、ポート監視などは、2台のZabbixプロキシから監視対象に接続ができれば問題ないです。   Zabbixエージェント（パッシブ） zabbix_agentd.confもしくはzabbix_agent2.confに、2台のZabbixプロキシから接続ができるように設定をします。 vi /etc/zabbix/zabbix_agent2.conf Server=10.0.2.155,10.0.2.230 ※カンマ区切りでZabbixプロキシのアドレスを指定します。   Zabbixエージェント（アクティブ） zabbix_agent.confもしくはzabbix_agent2.confに、2台のZabbixプロキシに接続ができるように設定をします。 vi /etc/zabbix/zabbix_agent2.conf ServerActive=10.0.2.155;10.0.2.230 ※セミコロン区切りでZabbixプロキシのアドレスを指定します。カンマ区切りにすると2重でヒストリデータが作成されます。   SNMPトラップ Zabbix7.0では対応しておりません。Zabbixサーバに送信する必要があります。 切り替わることを想定して、2台のZabbixプロキシに同じ内容のSNMPTrapを送信すると、2重でヒストリーデータが作成されます。   Zabbixトラップ Senderコマンドでデータを送信する場合、Zabbixプロキシの指定を以下のconfigを指定するようにします。 config内の「ServerActive」に指定しているプロキシが使用されます。 zabbix_sender -c /etc/zabbix/zabbix_agent2.conf -s <ホスト名> -k <アイテムキー> -o 1234 ※「-z」オプションで各プロキシを指定すると、2重でヒストリーデータが作成されます。   実際にフェイルオーバーしてみた 検証内容 以下の内容で検証を行います。フェイルオーバーの期間はデフォルトの1mとします。 １．各アイテムタイプで10秒間隔の監視アイテムを作成します。 ２．監視を行っている側のプロキシのサービスを停止します。 ３．フェイルオーバー後にヒストリを確認し、何秒間のデータが欠損したか確認します。 予想では、1m(フェイルオーバーの期間) + 10s(監視間隔) = 70秒＋αのデータ欠損が発生する想定です。   アクティブプロキシの場合 アイテムタイプ 監視内容 最終取得時間 再開時間 欠損 シンプルチェック ping監視 18:43:23 18:44:53 90秒 Zabbixエージェント（パッシブ） CPU使用率 18:43:25 18:44:55 90秒 Zabbixエージェント（アクティブ） CPU使用率 18:43:26 18:44:49 93秒 Zabbixエージェント（アクティブ） ログ 18:43:29  18:43:29 なし 再開後、切り替え期間中に発生したログも受信 Zabbixトラップ ー 18:43:27 18:44:47 90秒   パッシブプロキシの場合 アイテムタイプ 監視内容 最終取得時間 再開時間 欠損 シンプルチェック ping監視 18:58:43 19:00:13 90秒 Zabbixエージェント（パッシブ） CPU使用率 18:58:45 19:00:05 80秒 Zabbixエージェント（アクティブ） CPU使用率 18:58:46 19:00:04 78秒 Zabbixエージェント（アクティブ） ログ 18:58:39 19:00:04 なし 再開後、切り替え期間中に発生したログも受信 Zabbixトラップ ー 18:58:49 19:00:09 80秒   考察 ・フェイルオーバー期間(60秒)を考慮すると、30秒程で切り替えができました。通常は5分間隔の監視が多いため、タイミングによっては1回監視に失敗する程度かと思います。 ・ログ監視は、欠損なく監視が継続できました。監視再開後に切り替え期間中に出力されたログもZabbixサーバに送信されてきます。 ・Zabbixトラップで送信した内容は欠損します。zabbix_senderコマンドの実行結果がエラーになるため、送信元で制御する必要があります。もしくは、ZabbixAPIに「history.push」 がバージョン7.0から追加されましたので、変更することも考えてもよいと思います。   非機能要件について バックアップ ・プロキシサーバのデータベースに格納されるデータは一時データであるため、DBのダンプの保存は不要です。 ・/etc/zabbixは以下にコンフィグファイルがあるため、設定変更時にバックアップが必要です。   プロキシの監視 ・Zabbixサーバから直接(プロキシを経由せずに)監視を行うのが良いと考えております。プロキシを経由すると「接続エラーやダウン」なのか「データの取得エラー」か判別しにくいためです。 ・Zabbixプロキシのテンプレートは「Remote Zabbix proxy health」がデフォルトで用意されています。使用時にはマクロの設定が必要です。   メンテンナンス ・マイナーバージョンアップの方法について、別途ブログ記事にする予定です。   拡張性 ・プロキシーグループにプロキシサーバを追加することで容易に拡張できます。 ・障害発生時に縮退運転した際でも問題がないよう、リソースを準備する必要があります。   セキュリティ ・Zabbixサーバ　⇔　Zabbixプロキシ　⇔　Zabbixエージェント間の通信は暗号化することが可能です。「PSK」「証明書」と選択が可能です。   HA構成で気になること スプリットブレインについて もし、Zabbixプロキシで監視設定の情報を保持しているため、障害の状況によっては、両系のプロキシで監視を行う可能性はあると思います。 別途発生するか検証してみたいと思います。発生した場合の影響としては、以下と考えてます。 ・2重で障害を検知する。両系で取得したデータが保存されるため。 ・プロキシで保持している設定がZabbixサーバと同期されれば復旧する   フェイルバックについて 障害が発生したプロキシを復旧するだけで、Zabbixサーバは復旧を自動的に認識します。 復旧後自動的に監視対象のホストを分散します。（自動的に割り当てられるので、任意のプロキシに移動することはできません）   フェイルオーバー、フェイルバックを頻繁に繰り返す可能性について マニュアルを確認したところ、頻繁に切り替わりが発生した場合、対象プロキシを切り離すなどの設定はありませんでした。   まとめ プロキシグループを作成することで、簡単に冗長構成を構築することができます。 また、検知後30秒程度で切り替わりができております。さらにログ監視では欠損なく監視ができております。 SNMPトラップの監視ができませんので、要件を確認してご利用いただければと思います。   最後に 弊社では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アカウントを開設しました！★ x.com x.com

こんにちは、2024年度入社の冨岡です。 どうやら私は12月まで研修を受けさせていただけるようです。弊社の教育の手厚さを日々感じながら研修に取り組んでおります。 現在はクラウド（AWS）研修に取り組んでいる中で 作業証跡 というものを初めて聞き、そして感動しました。 作業証跡で 成果を客観的に示せたり 、 自分の操作の証拠を残せたり 、 研修の復習ができたり と利点がたくさんありました。なぜいままで証跡残すことを意識していなかったのかと反省してます。 今回は作業証跡に関して、画面キャプチャソフトである WinShot をクラウド研修を元に紹介します。 作業証跡とは 作業証跡 とは、自分の 操作に不正がないかどうかを客観的に示すための記録 を指します。 研修ではAWSのサービスに入力するパラメータ等の設定画面をキャプチャして、指示に沿っていることを記録しています。他にはアプリが正しく挙動しているかのテストが成功している様子を証拠に残したりしています。 WinShotの紹介 みなさんはスクショをどのように撮りますか？おそらくWindowsキー+Shift+Sでのやり方をされている人が多いかと思われます。少ない枚数ならばこのやり方で良いと思います。しかし研修ではlesson1だけで 64枚 のスクショをを撮りました。この枚数分Windowsキー+Shift+S押してると大変で非効率です。そこでWinShotが活躍します。ちなみに私はOJTの指導員からWinShotを教えてもらいました。 WinShotのダウンロード方法 http://www.woodybells.com/winshot.html からWinShotのzipファイルをダウンロードします。 解凍後、Winshotのアプリケーションファイルをダブルクリックして起動します。 何も起こらないように感じて不安になりますが、右下のタスクアレイにアイコンが存在すれば起動完了です。 これでもう使えます。 WinShotの使い方 まず設定から始まります。 WinShot右クリックで環境設定します。 基本設定 タブで保存するフォルダの指定をします。 ホット・キー タブでスクショのキーを確認できます。 私は ビットマップで保存(アクティブウィンドウ ）を主に使っています。 Ctrl + Shift + F7 押すと撮影したスクショを 自動でフォルダの中に保存 されていきます。これがすごく便利で作業効率が高まりました。 デフォルトの設定で名前が連番で割り当てられます。   業務では保存ファイル名が指定される場合もあるようです。 そんなときは基本設定で 保存ファイル名を毎回指定する(E) のラジオボタンを選んでください。 同様にCtrl + Shift + F7 押すと、ファイル名を付ける画面が出て保存が可能です。 研修概要 研修は将来的にフルスタック人材となるために必要な基礎テクノロジの取得を目的にされているため、アプリ・インフラの両方を扱っています。 今回は全部で9個あるlessonの内、最初のlesson1を紹介します。 この構成図通りに作ってみようがlesson1です。最後にはAWS環境にDeployしたアプリが起動するか、ブラウザからアクセスできることをテストして終了です。 具体的に例を挙げると No.15 No.17 このようなEC2やJavaの要件に沿って構築を進めていく研修になっています。 lesson1で撮ったこと No.15の指示に通りに作成し、No.17に取り組む際に入力したコマンドの証跡を残しました。 おわりに WinShotはインフラエンジニアの間では割と有名で良く使われているフリーソフトらしいです。これで自分もインフラエンジニアとしての第一歩を踏み出したのだなと 感無量 です。 次回の記事に関してですが、1月からの案件ではAzureを使うと聞いているので、次はAzureについて書きたいです。もしくは社会人になってから資格勉強にはまってるので資格関連も考えています。

こんにちは。 最近、ServiceNowのAutomated Test Framework（ATF）を使用する機会があったので、その際に学んだことのご紹介となります。 本記事は執筆時点（2024年10月）の情報です。最新の情報は製品ドキュメントを参考にしてください。 ATFとは ATFはServiceNowのインスタンス上で自動テストを作成・実行することが可能なツールです。 新しい機能を開発、リリースした時、インスタンスアップグレード後のリグレッションテスト時などで使用できます。 ATFには以下のような特徴、メリットがあります。 マニュアルで行っていたテストを自動化することによる生産性向上（テスト実行のスケジューリングも可能！） ローコード・ノーコードでテストを作成できるため、高度な開発技術が不要 テスト中に作成されたデータや設定変更はテスト終了後にロールバックされるため、インスタンスがクリーンな状態に保たれる データ破損、パフォーマンス影響などを防ぐ為、ATFによる自動テスト実行は非本番環境で実施してください。   ATFのコンポーネント 代表的なコンポーネントをいくつか記載します。 Test 後述するTest Stepをグルーピングするものとなります。 テストを実行する最小の単位であり、テスト対象となる1つ1つ機能や業務フローごとにTestを作成していくイメージとなります。 Test Step/Step Configuration Step Configurationは、ユーザーに成り代わる、メニューにアクセスする、フォームを開く、などの単一のアクションになります。OOTBで多くのアクションが用意されています。 そしてTest Stepではこれらのアクションを使用して、テスト項目の動作確認をするための1つ1つのステップ詳細を定義していきます。 例えば「Impersonate」というユーザーに成り代わる動作を行うことができるStep Comfigurationを使用する場合、どのユーザーに成り代わるのかをTest Stepで指定します。 たくさんのStep ConfigurationがOOTBで用意されていますが、個人的によく使用したものをいくつか紹介します。 Create a User 特定のグループ、ロールを持ったユーザーを作成します。作成したユーザーでそのまま代理操作することも可能です。 各ペルソナの権限で動作確認したい場合などに使用します。 Open a New Form / Set Field Values / Submit a Form  ３つを一緒に使用することで、「フォームを開く」「フィールドに値を入力する」「フォームをサブミット」するという一連の動作を再現することができます。 Order Catalog Item カタログアイテムをオーダーすることができます。 Record Validation レコードのフィールドの値が特定の条件を満たしているかを検証します。 Business ruleやScheduled Jobによる処理、ユーザーの操作などにより、フィールドの値が想定通りに更新されているか確認できます。 Test Suite 複数のTestをグルーピングしたものとなります。 Test Suiteを実行することで、紐づく全てのTestが自動で実行されます。そのため、ペルソナごと、業務内容ごとなどの切り口でTestをTest Suiteに紐づけグループ化することで、管理しやすくなります。 また、Test Suite内で各Testの実行順序を定義したり、Test Suiteを自動で実行するためのスケジュール設定も可能です。   例：全体の構成は以下のようなイメージとなります。 Test Suite システム運用者の運用業務 Test ①問題レコードを起票する ②変更レコードを起票する ③インシデントレコードを起票する （Test③に対する）Test Step/Step Configuration ①システム運用者のアカウントに代理操作する ②インシデントフォームを開く ③各項目を入力する ④フォームをサブミットする   ATFを使ってみる 以前作成した「User Registration Request」を使用して、①カタログアイテムをオーダーする、②部門長が承認する、③ユーザーが自動で作成される、というプロセスをATFで自動テストしてみます。詳細は以下記事をご参照ください。 ServiceNowⓇのNow Assistを活用してカタログアイテム（申請フォーム）とフローを効率的に作成する ServiceNowのNow Assistの機能を活用して、申請書とフローを作成してみました。非常に効率的に作成することができたので、そのプロセスをご紹介します。 blog.usize-tech.com 2024.08.27   その際、成功・失敗時のATFの動作を確認するため、以下２パターンでATFを実行します。 成功パターン ロールを持たない一般ユーザーで「User Registration Request」を申請する。 失敗パターン 「User Registration Request」を申請できる権限を「 user_admin 」に制限する。 ロールを持たない一般ユーザーで操作しようとしたが、権限が足りず申請することができない。 テストの作成 Automated Test Framework (ATF) > Testメニューから新規にTestを作成します。 その後、「Add Test Step」をクリックし、Test Stepを追加していきます。 追加したTest Stepは以下の通りとなります。 各ステップで行っていることは以下の通りとなります。 ①Creat a User 「User Registration Request」をオーダーするユーザーを作成して代理操作する。 この時、ユーザーの所属部署を「IT」に設定する。（=承認はIT部門長に設定したユーザー宛てに依頼される） ②Open a Catalog Item カタログアイテム「User Registration Request」を開く。 ※操作しているユーザーの権限が不足している場合、エラーとなる。 ③Set Variable Value 「User Registration Request」の各項目を入力する。 ④Order Catalog Item 「User Registration Request」をオーダーする。 ⑤Record Query リクエストアイテムが作成されていることを確認する。 ⑥Record Query IT部門長宛てに承認レコードが作成されていることを確認する。 ⑦Impersonate IT部門長のユーザーアカウントに代理操作する。 ⑧Open an Existing Record 自分宛ての承認レコードを開く。 ⑨Click UI Action UIアクション「Approve」をクリックして承認する ⑩Record Query ユーザーテーブルをクエリし、申請通りにユーザーが作成されていることを確認する。   Test Stepを追加していく際、各Test Stepのアウトプットは後続のTest Stepで利用することができます。 ④⑤のステップを例に説明すると、、 ④のOrder Catalog Itemではアウトプットとして、「Request」レコードが作成されます。 そして、⑤ではRequest Itemテーブルをクエリしていますが、クエリ条件に前ステップ④のアウトプットを使用しています。 設定は、画面上でポチポチするだけで完了します。   各ステップの詳細な設定手順は省きますが、基本ローコード/ノーコードで操作できるため、簡単に作成することができました。 テストの実行 「Run Test」をクリックし、テストを実行します。 テスト実行中は、以下の画面のようにテストの進捗を確認することができます。 テストの実行が完了しました。 「Go to Result」をクリックします。 Test Resultの画面では、各Test Stepごとの実行結果が確認できます。 また、画面操作などクライアント側のテストを実行した場合は、自動で画面のスクリーンショットを取得して添付してくれます。   次にテストが失敗した場合の動作を確認していきます。 「User Registration Request」をオーダーできる権限を「user_admin」に設定したうえでテストを実行します。 結果を確認すると、Test Step②のOpen a Catalog Itemでテストが失敗しています。 最初のステップで作成したユーザーが何も権限を持っていなく、「User Registration Request」を開けない為、失敗になったことが分かります。   感想 ATFを活用することで、テストに要する時間を大幅に削減することができると感じました。 また、アップグレードや新規機能リリース時、意図せぬ変更が行われていた場合の既存機能への影響検知に役立ちます。 今回は基本機能の一部分を紹介しましたが、他にも便利機能が多く用意されているので、引き続き勉強してアウトプットしていきたいと思います。   ServiceNow ServiceNowは、企業の生産性向上や業務プロセス改善を支えるサービスマネジメントクラウドソリューションです。従業員満足度・顧客満足度の向上、業務効率化を強力に支援します。 www.scsk.jp

こんにちは、SCSKの茂木です。 前回は「HULFT× LifeKeeper」についてご紹介しました。 第9回　HULFT × LifeKeeperでミドルウェアの高可用性を実現！ ミドルウェアの高可用性ニーズの高まりと、HULFTにLifeKeeperを用いてHA構成を実現する方法をご紹介いたします。 blog.usize-tech.com 2024.07.30 今回はデータのリアルタイムレプリケーションを実現する DRBD（Distributed Replicated Block Device）とLifeKeeperの可能性について探っていきましょう！   DRBDの概要 DRBD（Distributed Replicated Block Device）は、Linux環境で動作する ネットワークベースのストレージレプリケーションソリューションです。 主に高可用性クラスタを構築するために利用され、データのリアルタイムミラーリングを実現します。 DRBDは、ブロックデバイスレベルでのデータ同期を行い、物理的に離れたサーバー間でデータを複製します。   データのリアルタイムミラーリングは魅力的ね DRBDの特徴 続いてDRBDの4つの特徴について確認してみましょう。 DRBDを使用することでどのようなことができるのか、詳しく解説します。 ※DRBD9：DRBDの最新バージョンです。様々な機能が追加されました。 リアルタイムレプリケーション データをプライマリノードからセカンダリノードにリアルタイムで同期し、障害時のデータ損失を防ぎます。 通常のTCP/IPネットワークを利用してストレージの複製を行うネットワークレプリケーションを採用しているため、 特別なハードウェアを必要とせず、Linux環境とネットワークがあればすぐに導入可能です。 DRBD9では、Infini-Bandなどの高速ネットワークを活用することで、パフォーマンスの高い冗長化ストレージを提供します。 シームレスなストレージ冗長化 ファイルシステムよりも低いレイヤーで動作し、レプリケーションされたストレージをブロックデバイスとして提供します。 このデバイスは通常のストレージと同様に使用可能で、アプリケーションはミラーリングを意識せずに動作します。 これにより、リアルタイムでのデータ複製を行いながら、すべてのアプリケーションをシームレスに運用できます。 柔軟な構成 DRBDのマルチノード構成は、複数のノード間でデータをリアルタイムに同期し、システムの可用性を大幅に向上させます。 この構成により、単一障害点を排除し、データの一貫性を維持しながら、スケーラブルな環境を実現します。 特に大規模システムでの高可用性と信頼性を確保するために効果的です。 DRBD9からはメッシュ状に相互のノードを接続し、最大32ノードまでのレプリケーションが可能になりました。 オープンソース DRBDはオープンソースソフトウェアとして提供されており、コミュニティによるサポートと継続的な開発が行われています。 これにより、ユーザーは自由にソースコードを利用・改変でき、コストを抑えつつ最新の技術を活用できます。   Disaster Recovery add-on DRBDの理解が深まったところで、いよいよDRBD×LifeKeeperのご紹介です。 2024年9月25日より「LifeKeeper for Linux ver.9.9.0」において、 災害対策のための新たなオプション機能「Disaster Recovery add-on」の提供が開始されました。 「Disaster Recovery add-on」を使用し、DRBDリソースの設定と制御を行うことで、 遠隔地の災害対策サイトへのリアルタイムデータレプリケーションとアプリケーションのフェイルオーバーを行うことが可能になりました。 ここではDRBDやDataKeeperの問題点に注目することで、 「Disaster Recovery add-on」を使用するメリットを確認しましょう。 DRBDの問題点 手動管理 フェイルオーバーやフェイルバックは手動で行う必要があります。管理者が介入してノードの切り替えを行います。 監視機能の制限 DRBDはコマンドラインツールを通じて基本的なステータス（例：接続状態、同期状態）を確認できますが、 リソース監視等の詳細な監視や自動アラート通知機能はありません。 DataKeeperの問題点 マルチターゲット構成 DataKeeperは3ノード以上のマルチターゲット構成をサポートしていません。 非同期レプリケーション 非同期レプリケーションを使用することは可能ですが、パフォーマン面に課題があります。 Disaster Recovery add-onの使用 自動高可用性管理 DRBDのデータレプリケーション機能に加え、LifeKeeperは自動フェイルオーバーとフェイルバックを提供します。 障害発生時に自動でノードを切り替えることでダウンタイムを最小限に抑え、運用負荷を軽減します。 監視機能の拡張 リソースの状態を継続的に監視し、問題が発生した際にアラートを発します。 マルチターゲット構成（3ノード） Disaster Recovery add-onでは任意の同期モードを組み合わせた3ノード構成が可能です。 物理的・地理的な配置や利用可能なネットワーク環境、トランザクションの種類と量、転送されるデータ量などに応じて、 最適な同期モードを選択できます。 まとめ DRBD はデータのレプリケーションに特化しており、手動での管理が必要です。 DataKeeper は同サイトでのレプリケーションを想定しているため、DR環境での利用に適していません。 Disaster Recovery add-on は、DRBDの機能を拡張し、システム全体の可用性を高めるための自動化と管理機能を提供します。   製品ページ SCSKでは、LifeKeeperの製品ページをご用意しております。 「LifeKeeper」で安定稼働を実現 ｜ SCSK株式会社 「LifeKeeper」は、システム障害時にあなたのビジネスを守るＨＡクラスターソフトウェアです。オンプレ環境だけでなく、パブリッククラウド環境での安定稼働の実現にも最適です。長年培ったSCSK独自のノウハウでお客様の課題解決に向け最適なご... www.scsk.jp   ご参考までに、提供価格を提示いたします。 1年間の使用権とサポートをセットとしてサブスク型オプション製品として提供されます。 ※標準価格は1ノードあたり。LifeKeeperのライセンスと保守は別途必要。 最後に 今回はDRBDとLifeKeeperの可能性についてご紹介しました。 次回は実際に検証を行う予定ですので、ご期待ください！

既存のAWSリソースを基にCloudFormationテンプレートを生成する「IaCジェネレータ」が2024年2月にリリースされました。 このツールによって、既存のリソース情報を簡単にコード化できるようになっています。 8月にアップデートされた情報と合わせて、使ってみた感想、ポイントをご紹介します。 最新の情報については、AWS 公式ドキュメントをご参照ください。 IaCジェネレータとは AWS IaCジェネレータは、既存のリソースを基にCloudFormationテンプレートを生成できるサービスです。 テンプレートはJSONとYAML形式で出力できます。 こちらはCloudformationの機能の一部として提供されているので、マネジメントコンソールの[Cloudformation]のサービス画面から利用が可能です。   使い方 既存のリソース情報をスキャンし、スキャンされたリソースの中からコード化したいリソースを選択することで、テンプレートが作成できます。 ▼Cloudformationテンプレート化の方法 　1.　マネコンのCloudFormationから[IaCジェネレーター]のメニューを選択する。 　2.　[新しいスキャンを開始]をクリックする。 　3.　[テンプレートの作成]からテンプレートの詳細を指定し、テンプレート化したいリソースを選択して[スキャンしたリソースを追加]に追加する。 ※リソースはリソース識別子(ID等)、リソースタイプ(AWS::EC2::Instance等)、タグのいずれかでフィルター可能。 　4.　選択したリソースに関連するリソース一覧がデフォルトでチェックされた状態で表示されるので、必要に応じて追加選択する。 　5.　[テンプレートの作成]でテンプレートを作成する。以下は作成されたテンプレート。 ▼テンプレートを用いたリソース作成の方法 　1.　CloudFormationの[スタックの作成]>[新しいリソースを使用]を選択する。 　2.　[テンプレートの指定]でテンプレートを選択しスタックを作成する。   ちなみに、8月のアップデートは以下2点でした。 スキャンした内容に関して[スキャンされたリソースの内訳]が追加されました。製品タイプごとにフィルタリングし、円グラフを使って視覚的に表示することができます。   作成したテンプレートの[テンプレートの定義]がAWS Application Composer（AWSのビジュアルツール）で表示されるようになりました。 これにより、視覚的にリソースを容易に理解することが可能です。   コスト テンプレート化は無料で利用可能です。 ※Cloudformationで作成したリソースには利用料金が発生します。   制約事項 クォータ制限については、以下の表のとおり通り制約がありました。 1 回のアカウントスキャンで処理できるリソースの最大数 100,000 1日あたりのスキャン数 (リソースが 10,000 未満のアカウントの場合) 3 1日あたりのスキャン数 (リソースが 10,000 以上のアカウントの場合) 1 アカウントあたりの同時に生成されるテンプレートの数 5 1回のテンプレート生成で同時にモデル化されるリソースの数 5 1つのテンプレートでモデル化できるリソースの合計数 500 生成されたテンプレートのアカウントあたりの最大数 1,000 追加で、 スキャンは30日間のみ有効なためそれ以降は利用できなくなる こと、 スキャン後に削除されたリソースに関してはテンプレート対象として選択できない 点に注意です。 また、 スキャンはアカウント内の全リソースに対しておこなわれる（特定のリソースのみのスキャンは不可である） ことから、リソース数が多い環境では時間に余裕をもってスキャン実施することをお勧めします。 公式情報によると「1,000リソースで10分程度かかる可能性がある」とのことで、実際に自分が検証で30,000近くのリソースがある環境でスキャンした際は50分程かかりました。   テンプレート作成時の注意点 IaCジェネレータでテンプレートを生成してみて、個人的に引っかかったポイントです。 テンプレート作成時のリソース検索は、「リソース識別子(ID等)、リソースタイプ(AWS::EC2::Instance等)、タグ」のいずれかでフィルター可能ですが、 検索文字列はいずれも完全一致の必要有り でした。またリソース名で検索は不可です。 テンプレート作成時に「関連リソース」としてテンプレート化するリソースがレコメンドされますが、レコメンドされるリソースの判断基準は不明のようです。 ※AWSサポートに問い合わせると「現在のところ公開している情報がなく、AWS 内部の仕組みのため案内は難しい」と回答有り テンプレート化したリソースの更新・削除ポリシーは デフォルトが”保持” になっています。 この設定により、Cloudformationのスタックを削除しても作成されたリソースは削除されず保持されます。 Cloudformationで一からテンプレートを作成する場合このポリシーは”削除”がデフォルトのため、仕様の違いに注意です。 EC2はテンプレート内で指定しているAMIが現在存在していない場合、テンプレートを使ってリソースを構築することはできません。 テンプレート内のリソース参照がハードコードされている場合、別のアカウントで同じリソースを作成しようとすると、そのアカウントの情報に合わせてテンプレートを修正する必要があります。 テンプレートには、AWSマネコンでは直接表示や設定ができないリソースタイプ（例: “AWS::EC2::EIPAssociation” や “AWS::Lambda::Version” など）が含まれることがあります。 リソースタイプは普段マネコンからリソース作成していると馴染みが薄いかもしれませんが、Cloudformationのユーザーズガイドにリソースタイプリファレンスとしてそれぞれの意味や構文などの説明が記載されているので参考にしてみてください。   また、Cloudformationの仕組みとして、以下はマネコン上で構築する際と異なるルールになりますので、Cloudformation初心者の方はお気を付けください。 リソースの設定内容によってはCloudformationテンプレートで設定できないものもあります。（リソース作成後マネコンから設定可能） テンプレートで構築するEC2はリソース定義するのみのため、内部のソフトウェアやデータ構成など中身は反映されません。 ユーザデータにスクリプトを書き込んでおくなど別途対応が必要になります。   活用できそうな場面 構築では、 同じ環境を複製したい場合、同等の環境を作成したい場合、アカウントをまたいでリソースを移行したい場合 に 運用では、 リソースを棚卸したい場合、リソースの依存関係を可視化したい場合、現状のリソースの設定状況を保管しておきたい場合（変更管理） に また、 BCP用、不要リソースの削除前のバックアップ にも活用できそうです。   みなさまも色々IaCジェネレータを触ってみて、活用方法をぜひ考えてみてください。

こんにちは。SCSKの上田です。 システム監視の重要度が高まってきた昨今、様々な監視ツールが存在しています。 今回は、 オープンソースのシステム監視ツール「 Zabbix 」 と、 AWSの「 Amazon CloudWatch （以下、CloudWatch）」 を比較してみました。 監視ツール選定のご参考になれば幸いです。 ZabbixとCloudWatchの概要 まずは、 Zabbix と CloudWatch 、それぞれの概要について説明します。 Zabbixについて Zabbixは、 エンタープライズ対応のオープンソース統合監視ツール です。 サービスやそれを支える ITシステム(サーバ、ネットワーク機器等)の状態を把握し、障害の予兆やサービスへ影響を及ぼす事象が発生した際に、システム管理者やオペレータに通知を行うことができます。 オープンソースのため無料で導入でき、数万デバイス規模のエンタープライズ環境でも多数の稼動実績を誇っています。 Zabbixの詳細情報については、下記リンクよりご確認ください。 Zabbix :: The Enterprise-Class Open Source Network Monitoring Solution ZabbixはITインフラストラクチャ・コンポーネントの可用性やパフォーマンスを監視するためのエンタープライス向けソフトウェアです。Zabbixはオープンソース・ソフトウェアとして開発されており、無料でダウンロードいただくことが可能です。 www.zabbix.com CloudWatchについて CloudWatchは、 AWS が提供するクラウドネイティブな監視サービス です。EC2、Lambda、S3といったAWSの各種サービスのパフォーマンスデータも収集・追跡し、AWS環境全体の監視ができます。 CloudWatchは、AWSコンソールから簡単に設定・利用できるため、導入の手間が少なく、初心者にも扱いやすいのが特徴です。また、監視対象のAWSサービスやメトリクス、アラート設定などを柔軟にカスタマイズできるため、大規模で複雑なシステムにも対応可能です。 CloudWatchの詳細情報については、下記リンクよりご確認ください。 Amazon CloudWatch（リソースとアプリケーションの監視と管理）| AWS Amazon CloudWatch は、AWS リソースと AWS で実行するアプリケーションのモニタリングサービスです。様々なメトリクスやログを収集・追跡することで、システム全体のリソース使用率、アプリケーションパフォーマンス、およびオペ... aws.amazon.com ZabbixとCloudWatchの比較 それでは、 Zabbix と CloudWatch を比較してみましょう。 比較表 ざっくり比較すると、以下のようになります。 比較項目 Zabbix CloudWatch 概要 オープンソースの監視ツール AWSのマネージド監視サービス コスト ソフトウェア自体は 無料 AWS上に構築する場合EC2料金、 サポート入るなら年間サポート料金 従量課金制 （監視項目数に応じた課金） 監視対象 クラウド・オンプレどちらも対応 サーバー、ネットワーク機器、アプリケーションなど、多岐にわたる AWSのリソース （EC2、S3、Lambdaなど） 監視項目 CPU、メモリ、ディスク、プロセス、ログ、SNMP監視など （一部監視にはエージェント導入必要） CPU、メモリ、ディスク、プロセス、ログなど （一部監視にはエージェント導入必要） 監視対象数 無制限（サーバのスペックに依存） 無制限 導入難易度 ある程度の技術知識が必要 AWSの知識があれば 比較的容易 サポート Zabbix Enterpriseサポート AWSの公式サポートとコミュニティ いくかの比較項目について、詳しく解説していきます。 コストについて Zabbixはオープンソースソフトウェアのため、ライセンス費用無料で監視を行うことが可能です。何台監視しても、どれだけ監視項目を増やしても、無料で使用することができます。 但し、AWS上に導入する場合はEC2の費用が発生するのと、サポートに加入する場合はサポート費用が発生します。 CloudWatchは従量課金制です。Cloudwatchのリソース監視には標準メトリクスとカスタムメトリクスの2種類があり、標準メトリクスであれば無料ですが、カスタムメトリクスの場合はメトリクスの数だけ料金が発生します。 簡単にコスト比較をしてみましょう。 （2024年10月時点でのコスト比較です） コスト Zabbix CloudWatch サーバ t3.smallを使用したとすると、 0.0272$ /h　→約20$ /月 – 監視対象 – 1サーバあたり10個カスタムメトリクスを利用したとすると、 0.30$/月 * 10 = 3.0$/月 →3.0$ /月・監視台数 合計 20$/月 3.0$ /月・監視台数 この結果から、 監視対象が7台を超えるとZabbixの方が安い ということになります。 但し、 EC2のスペック や カスタムメトリクスの数 によって料金が変動するため、一概にこのシミュレーションが正しいとは限りません。 あくまで参考値として捉えてください。 詳細なコストについては、AWS公式サイトをご覧ください。 料金 - Amazon CloudWatch | AWS Amazon CloudWatch は無料で始めることができ、また 、無料利用枠内でご利用いただけるアプリケーションも多数ご用意しています。このページでは Amazon CloudWatch に関する各種お見積もりや API 使用時のコスト... aws.amazon.com 監視対象、項目について Zabbixは、クラウド・オンプレ問わず、サーバやネットワーク機器、アプリケーションなど様々なリソースを監視することができます。監視項目も幅広く、既存のアイテムキーに加え、APIを作り込めば様々なデータを取得し監視することが可能です。 CloudWatchは、AWSのマネージドサービスというだけあり、AWS上のリソース監視に特化しており、他クラウドやオンプレミスの監視には不向きです。（CloudWatchでも作り込みによってはオンプレ環境の監視はできますが、設定が煩雑です） また、監視項目は、標準メトリクス（死活、CPUなど）は無料ですが、カスタムメトリクス（メモリ、ディスク、プロセス）については有料となっています。 導入難易度について Zabbixは、GUI操作で監視の設定が行えるのですが、柔軟性が高い反面設定が難しく、慣れるまでが大変です。例えば「CPU使用率を監視したい」と思っても、ホストの登録・アイテムの設定・トリガーの設定など手順が多く、アイテムキーの設定もマニュアルを読まないと分かりにくい部分があるため、慣れるまでが大変です CloudWatchは、GUIの直感的な操作で監視の設定ができるため、AWSに慣れている人なら比較的簡単に設定できると思います。 それぞれでAWS上に建てたEC2のCPU使用率を監視する方法を見比べてみましょう。 まずはZabbixからです。Zabbixのインストール、監視対象へのAgentのインストールは完了している前提とします。 Zabbixのインストールについては、以下の記事をご参照ください。 LinuxサーバーへのZabbixインストール手順 オープンソースの統合監視ツールである「Zabbix」を、Linuxサーバーへインストールする手順を紹介します。 blog.usize-tech.com 2024.02.13 ①WEBコンソールから、監視対象機器（ホスト）を登録する Zabbix設定手順① ②登録したホストにアイテムを設定する Zabbix設定手順② ③登録したホストにトリガーを設定する Zabbix設定手順③ 以上で設定は完了です。設定手順自体は少ないですが、アイテム設定の”アイテムキー”、トリガー設定の”トリガー条件式”の書き方は、様々な項目の監視や複雑な条件式が書ける反面、 慣れるまで難しい と思います。 より複雑な設定を行いたい場合、Zabbix公式ドキュメントを読んでいただくか、 ZabbixのEnterpriseサポートに加入いただくこと をお勧めいたします。詳細は弊社のZabbix特設ページをご覧ください。 SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします www.scsk.jp 続いて、CloudWatchの設定手順です。 ①CloudWatchのコンソールから、アラームを作成する CloudWatch設定手順① ②監視対象のメトリクスを選択する CloudWatch設定手順② ③閾値を設定する CloudWatch設定手順③ ④アクションを設定する（SNS通知、EC2へのアクションなどが設定できます） CloudWatch設定手順④ ⑤アラーム名を設定する CloudWatch設定手順⑤ 以上で設定は完了です。設定手順は多く見えますが、一連の流れで全ての設定が直感的に行えるため、Zabbixに比べて簡単に設定できると思います。 結局、どちらを選ぶべき？ ここまでの比較から、ZabbixとCloudWatchの強みと弱みをまとめます。 比較項目 Zabbix CloudWatch 強み ・柔軟な監視設定 ・広範囲な監視対象 ・コスト効率が高い ・豊富なAWSサービスとの連携 ・導入が容易 弱み ・導入・運用に技術知識が必要 ・サーバーのサイジングが必要 ・監視の対象がAWSに限られる ・高度な監視にはコストがかかる Zabbixは、 クラウド・オンプレ問わず様々な監視 ができ、 コストも抑えられます 。しかし、導入や運用には知識が必要です。 CloudWatchは、 AWS上のリソース監視を簡単に設定 することができます。しかし、AWS以外の監視には向いておらず、コストもかかってしまいます。 以上のことから、以下のように選択すると良いと思います。 マルチクラウドやオンプレミス環境で、コストを抑えたいなら、 Zabbix AWS環境で、手軽に監視をしたいなら、 CloudWatch   まとめ 今回は、 Zabbix と CloudWatch の比較を行ってみました。 それぞれメリット・デメリットがありますので、皆様の環境に合わせて、最適な監視ツールを選択してください。 弊社では、 Zabbixの導入もAWSの設計構築も行っています。 「Zabbixを使いたいけど、使い方が分からない・・・」 「結局どの監視ツールを使えばいいのか迷っている・・・」 などなど、監視についてお悩みの点がありましたら、是非弊社までお声がけください！ 最後まで読んでいただきまして、ありがとうございました。 弊社では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アカウントを開設しました！★ x.com x.com

こんにちは、SCSK株式会社の小寺崇仁です。 Zabbixには定期レポート機能があります。今回は定期レポートの設定方法を紹介いたします。 定期レポートとは Zabbix5.4にて実装された、定期的にダッシュボードのスクリーンショットをPDF形式で通知する機能です。 以下のファイルが「application-pdf」というファイル名で通知されます。 設定方法 Chromeのインストール dnf install https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm dnf install google-chrome-stable Zabbix-Web-Serviceのインストール＆設定 dnf install zabbix-web-service systemctl start zabbix-web-service vi /etc/zabbix/zabbix_server.conf StartReportWriters=1 WebServiceURL=http://localhost:10053/report 作業ディレクトリの作成 mkdir /var/lib/zabbix chown zabbix:zabbix /var/lib/zabbix/ Web管理画面のURLを設定 「管理」->「一般」->「その他」を開きます。 WebインターフェースURLにZabbixサーバのWeb管理画面のURLを指定します。 レポートの作成 「レポート」->「定期レポート」->「レポートの作成」を開きます。 名前 任意 ダッシュボード 任意 （レポートにしたいダッシュボード） 期間 前日、先週、先月、去年 (ダッシュボードに表示するデータの期間) 周期 毎日、毎週、毎月、毎年 （レポートを送信する間隔） 配信先 配信先ユーザ ※メディアタイプの設定が必要です。 通知 メールのメディアタイプを設定した場合、以下の様に通知されます。 最後に ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ https://www.youtube.com/channel/UC-_Jh3K46ZM610HUNtsArtQ/videos ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ https://x.com/SCSK_Zabbix

こんにちは。SCSK株式会社の南です。 11/6 に、 【「Prisma Cloud」運用課題を解決、成功事例に学ぶ「CSPM」運用改善アプローチ ～未解決アラートへの対策など具体的な解決策を紹介～】 と題したPrismaCloudのセミナーを開催します。 本セミナーでは、Prisma Cloudの運用課題を解決したいと考えている方を対象に、運用改善のための具体的な手法と成功事例をご紹介します。 特に「なぜアラートの対応が進まないのか」に焦点を当てて解説してまいります。   セミナー概要 主催・協力 SCSK株式会社株式会社 オープンソース活用研究所 マジセミ株式会社 日時 2024-11-06（水）13:00 – 14:00 会場 Webセミナー ツールはZoomを使います。URLは直前にメールにてご連絡いたします。 対象 Prisma Cloudをご利用いただいており、運用に課題を抱えている方 Prisma Cloudにご興味ある方 参加費 無料   プログラム詳細とお申込みは、以下ページをご参照ください。 （SCSK） 「Prisma Cloud」運用課題を解決、成功事例に学ぶ「CSPM」運用改善アプローチ ～未解決アラートへの対策など具体的な解決策を紹介～ 2024-11-06（水）13:00 - 14:00 当お申込ページはSCSK株式会社経由の方向けのお申込みページです。 一般の方はこちらからお申し込みください。 本セミナーはWebセミナーです ツールはZoomを使います。URLは直前にメ... majisemi-security.doorkeeper.jp   最後に 弊社ではPrisma Cloud関連サービスを展開しています。以下ページもご参照ください。 ★パブリッククラウドのセキュリティ設定を監視し異常を速やかに検知する、Prisma Cloudを活用した「 マネージドCSPMサービス 」はこちら！ Smart One Cloud Security® パブリッククラウドのセキュリティ設定を診断/監視するマネージドCSPMサービスです。Palo Alto Networks社Prisma Cloud（CSPM機能）を使い易く、簡単に導入いただけます。 www.scsk.jp ★パブリッククラウドのセキュリティ設定に対する現状確認やリリース前診断が、お手軽に可能な「 スポット診断サービス 」はこちら！ マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp

昨今のビジネス環境では、コスト削減やスケーラビリティの向上、リモートワークの促進など、多くの利点を提供するクラウドサービスの利用が急速に拡大しています。しかし、その一方で、 パブリッククラウド環境には特有のセキュリティリスクが存在 しているため、データ漏洩や不正アクセス、サイバー攻撃などの脅威から企業の重要な情報を守るためには、 クラウドセキュリティの強化が必要不可欠 となっています。 ここでは、「クラウドセキュリティ」 がどのようにあるべきか、そしてそれをどのように進めるべきかを、「 今やるべきクラウドセキュリティ対策とは？ 」と題して解説します。 パブリッククラウドにおける昨今のセキュリティリスク まず初めに、パブリッククラウドにおけるセキュリティリスクにはどのようなものがあるでしょうか。Cloud Security Alliance（CSA）により2022年に「 Top Threats to Cloud Computing ‒ Pandemic Eleven 」が公開されていますが、その すべてにおいて利用者側に責任が発生する 脅威 となっています。パブリッククラウド環境の機能追加や利用者側の用途拡大に伴い、これらセキュリティリスクの多様化は年々進んでいるため、組織はこれらの動向確認とその対処や対策が急務と言えます。 順位 脅威名 1 不十分なアイデンティティ、クレデンシャルおよびアクセスと鍵の管理、ならびに特権アカウント 2 セキュアでないインターフェースやAPI 3 設定ミスと不適切な変更管理 4 クラウドセキュリティのアーキテクチャと戦略の欠如 5 セキュアでないソフトウェア開発 6 セキュアではないサードパーティーのリソース 7 システムの脆弱性 8 予想外のクラウドデータ公開 9 サーバレスやコンテナワークロードの構成ミスやエクスプロイト 10 組織的な犯罪、 ハッカーとAPT 11 クラウドストレージデータ流出 【出典】CSA、Top Threats to Cloud Computing ‒ Pandemic Eleven 　       （日本語訳：CSA ジャパ ン「クラウドコンピューティングの重⼤脅威 パンデミックイレブン」）     　    https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2022/11/top-threats-to-cloud-computing-pandemic-eleven-060622-en_us-ja.pdf   クラウドセキュリティ対策のあるべき姿 では、これらのセキュリティリスクに共通する対策は何でしょうか？ それは 「 発見 」 と 「 対応 」 そして、それらを 「 継続して確認すること 」 と考えます。 Gartner社は、サイバーセキュリティの新たなアプローチとして2022年に 継続的な脅威エクスポージャー管理（ CTEM ：Cloud Threat Exposure Management） を提唱し、これを2023年に続き2024年のサイバーセキュリティ トップ・トレンドの一つとして掲げています。 *1 *1 2024年2月27日　 Gartner 2024年のサイバーセキュリティのトップ・トレンドを発表       https://www.gartner.co.jp/ja/newsroom/press-releases/pr-20240227   CTEMとは？ では、CTEMとはどういったものでしょうか。 CTEMは、組織がサイバー攻撃を受ける可能性のあるリスクや脆弱性の状態（攻撃面）をIT資産全体で特定し、それを継続的に評価し、対応するためのフレームワークであり、これを導入することでサイバー攻撃によるリスクを大幅に軽減できるとされています。 「一度作ったらずっと安全」 というシステムはほとんど存在しないため、このような継続的管理は必然的だと言えます。 CTEMフレームワークは以下の5つのステップで構成されています。   No. Step 説明 1 範囲の設定 （Scoping） 保護すべき資産やシステムの範囲を決定します。 2 発見 （Discovery） 脆弱性や攻撃経路などのリスクを発見し評価します。 3 優先順位付け （Prioritization） 発見された脆弱性やリスクを優先順位付けし、修正の順序を決定します。 4 検証 （Validation） 対策の有効性を確認するために、シミュレーションやテストを行います。これにより、対策効果を事前に評価し、それが十分であるかを確認します。 5 動員 （Mobilization） 検証結果に基づき、組織のセキュリティ体制強化と対策を実施します。セキュリティ体制では、セキュリティ担当と運用担当との連携も必要となります。 1～3は診断フェーズとして、対象範囲の特定と、その範囲における問題の把握と優先順位付けを行います。 4、5は行動フェーズとして、対策の事前検証と、検証結果に問題がなければ対策を実施します。 これらを 定義した 「範囲の設定」毎に繰り返し実施 することで、組織におけるサイバーリスクの継続的な評価・対策を実現することができます。また、一連の動作すべてを単一ソリューションでまかなう必要はなく、環境に応じて手動運用とソリューションの組み合わせなどで実現することも有効な手段となります。 CTEMの具体的な指標としてGartner社は、2026年までにCTEMの考えに基づき継続的にセキュリティ投資を行っている組織について、セキュリティ侵害を3分の1まで減らせるようになるとみています。   【クラウドセキュリティ対策のあるべき姿】 CTEMを活用 して 脅威の発見と対応を継続的、効果的に管理 すること   パブリッククラウドを取り巻くセキュリティ対策 さて、クラウドセキュリティ対策のあるべき姿が理解できたところで、実際にパブリッククラウドで 実施すべきセキュリティ対策のソリューションや機能 に何があるかを見てみましょう。   まずは利用形態のご紹介ですが、パブリッククラウドは大きく分けて、IaaS、PaaS、SaaSのモデルに分類されます。 IaaS（Infrastructure as a Service）: インフラストラクチャをサービスとして提供するモデルで、ユーザーは仮想マシンやストレージ、ネットワークなどのリソースを必要に応じて利用できます。代表的なサービスには、Amazon Web Services（AWS）やMicrosoft Azure、Google Cloudがあります。 PaaS（Platform as a Service）: アプリケーション開発に必要なプラットフォームを提供するモデルで、開発者はインフラの管理を気にせず、アプリケーションの開発とデプロイに集中できます。例として、Google App EngineやMicrosoft Azure App Servicesがあります。 SaaS（Software as a Service）: ソフトウェアをサービスとして提供するモデルで、ユーザーはインターネットを通じてソフトウェアを利用でき、インストールやメンテナンスの手間が省けます。代表的なサービスには、Google WorkspaceやMicrosoft 365、Salesforceがあります。 これらのモデルごとに適した、主なセキュリティ対策としては以下のようなものがあります。   EASM (External Attack Surface Management) 外部攻撃対象領域（インターネットに公開されている入口）を管理し減少させるための取り組みで、管理されていない対象も洗い出します。組織の外部から見える脆弱性を特定し、それを解消することを目的としています。 CNAPP (Cloud Native Application Protection Platform) IaaS、PaaS領域に対応した、クラウドネイティブなアプリケーション保護を目的とし、設定ミスや脆弱性の管理、統一した設定などのガバナンス強化を行うためのセキュリティプラットフォームです。通常、マルチクラウドに対応します。 CSPM、CWPP、CIEM、IaCセキュリティ *2  が主な構成要素です。 SSPM (SaaS Security Posture Management) SaaS領域の適切なセキュリティ設定から逸脱した状態を検出し、データの保護を強化します。ソリューションによって対応可能なSaaS環境が異なります。 DSPM (Data Security Posture Management) データのセキュリティ態勢を包括的に管理します。重要データの検出を行ったり、データが保管・処理される全ての段階でセキュリティを確保し、データ漏洩や不正アクセスを防ぐことを目的としています。   パブリッククラウド環境においては、これらの異なる目的と役割を持つソリューションを活用し、 互いを補完しつつ全体のセキュリティを強化 することが重要となります。 *2  CSPM (Cloud Security Posture Management)：IaaS/PaaSのセキュリティ設定不備を監視し、リスクを可視化するソリューション 　　CWPP (Cloud Workload Protection Platform)：IaaS/PaaSのワークロードを監視し、脅威を検知するソリューション 　　CIEM (Cloud Infrastructure Entitlement Management)：IaaS/PaaSの権限侵害を検知し、セキュリティを強化するソリューション 　　IaCセキュリティ (Infrastructure as Codeセキュリティ)：コードの構成ミスやセキュリティリスクを検知するソリューション   今やるべき「クラウドセキュリティ」対策 ここまでで、パブリッククラウドにおける セキュリティ対策のあるべき姿 (CTEM) と セキュリティ対策のソリューションや機能 (EASM・CNAPP・SSPM・DSPM) の概要をお伝えしてきました。CTEMに基づいて、それぞれのセキュリティ対策を実施することで、安全・安心なクラウド環境を維持することが可能となります。理想はすべてのセキュリティ対策をあるべき姿で運用することですが、それらを一度に適用するのが困難であることは、言うまでもありません。   ここでは、 クラウドセキュリティ対策を効果的に進める ための流れについて、ベストプラクティスをご紹介します。   IaaS・PaaSの場合 IaaS・PaaS環境の場合は、下記の対策順で適用することが効率的と考えます。 環境によっては、既に導入済のソリューション・機能がある場合や、導入予定のサービスが複数機能を有していることから、適用順が変わる場合があるかもしれません。ここでの説明は、あくまでも効率よく進めるための参考として捉えて頂き、状況に応じて柔軟に対応頂ければと思います。   運用フレームワーク CTEM  ソリューション・機能 CNAPP (CSPM、CWPP、CIEM、IaCセキュリティ) 、EASM、DSPM 対策順 EASM → CSPM → IaCセキュリティ → DSPM → CIEM → CWPP １. EASMの適用 最初にEASMを適用します。最初に適用することによって、攻撃者にとっての「入口」を早期に閉じることができ、外部攻撃に対する脆弱性が減少します。基本的に企業が有するドメインやIPアドレスなどの情報から「入口」を発見するため、SaaS環境を利用中の場合は、同時に適用できる場合があります。（使用するソリューションに依存） ２. CSPMの適用 次にCSPMを適用します。基本的なセキュリティ設定やポリシーの監視を行い、この段階でインフラストラクチャにおけるセキュリティのベースラインを確立します。 ３. IaCセキュリティの適用 IaCを利用している場合は適用します。IaCセキュリティを導入することで、一貫したセキュリティ設定が自動的に適用され、構成のドリフト(設定と実態で差異が生じること)を防止します。CSPMと同様にこの時点でインフラストラクチャのセキュリティベースラインを確立します。 ４. DSPMの適用 CSPM/IaCセキュリティの次に適用する事で、通信経路などのインフラストラクチャに関する基本設定が整った後となるため、効果的なデータセキュリティ対策を行うことが可能となります。 ５. CIEMの適用 続いて、CIEMを適用します。DSPMによって新たな重要データの発見や、その管理が確立した後に適用することで、合理的かつ適切にデータのアクセス権限管理が可能となります。 ６. CWPPの適用 最後にCWPPを適用します。CWPPは、リアルタイムでマルウェアや攻撃からの防御を提供するため、他のセキュリティ対策が確立された後に導入することで、脆弱箇所が限定されるなど、ワークロードを効果的に総合的に保護できます。   SaaSの場合 SaaS環境の場合は、下記の対策順で適用することが効率的と考えます。 基本的な考え方はIaaS・PaaS環境と同様ですが、SaaS環境の方が必要な機能が狭まるため、対応するソリューションはシンプルな構成で済みます。   運用フレームワーク CTEM ソリューション・機能 SSPM、EASM、DSPM 対策順 EASM → SSPM → DSPM １. EASMの適用 最初にEASMを適用します。EASMによって外部からの脅威を迅速に特定することで、IaaS・PaaS環境と同様に、攻撃者にとっての「入口」を早期に閉じることができるため、外部攻撃に対する脆弱性の減少が行えます。こちらもIaaS・PaaS環境を利用中の場合は、同時に適用できる場合があります。（使用するソリューションに依存） ２. SSPMの適用 次にSSPMを適用します。SSPMによってSaaSアプリケーションのセキュリティ設定を確立し、内部リスクを管理します。この時点でクラウド環境全体のセキュリティベースラインを確立します。環境によっては、EASMより先にSSPMを実施した方がリスク低減が図れる場合があります。 ３. DSPMの適用 最後にDSPMを適用します。SaaS環境における内部・外部のセキュリティ対策が整備された後に、データの保護、分類、監視を行うことで、効果的にデータセキュリティ対策が行えます。   IaaS・PaaS環境、SaaS環境の何れの場合においても、どのリスクに重きを置くかによって適用順を見直すことは必要です。また、何れの対応においてもCTEMフレームワークに沿って運用することで、効果的かつ強固なセキュリティ対策を実現することが可能となります。   まとめ クラウドコンピューティングの普及に伴い、クラウドセキュリティの重要性が高まってる一方で、パブリッククラウドには数百にも及ぶ多くのサービスが存在しているため、それらの 設定すべてを人の手で確認することは非常に困難な状況 となっています。 しかも、攻撃者による「脆弱性の発見」から「攻撃」までにかかる時間は年々短縮されているため、組織側の確認・対応サイクルを短くすることも求められます。 このような背景から、 効率よく運用する ためには 専用のソリューションがオススメです。 当社では、IaaS・PaaS環境のセキュリティ対策に適した「 EASM 、 CSPM 、 IaCセキュリティ 、 DSPM 、 CIEM 、 CWPP 」を全て備えた Prisma Cloud を提供しています。また、CSPMに関しては、簡単導入・簡単診断が可能な下記のサービスもありますので、ご興味ある方は是非、お気軽にお問い合わせください。 パブリッククラウドのセキュリティ設定を監視し異常を速やかに検知する、Prisma Cloudを活用した「 マネージドCSPMサービス 」 はこちら！ Smart One Cloud Security® パブリッククラウドのセキュリティ設定を診断/監視するマネージドCSPMサービスです。Palo Alto Networks社Prisma Cloud（CSPM機能）を使い易く、簡単に導入いただけます。 www.scsk.jp パブリッククラウドのセキュリティ設定に対する現状確認やリリース前診断が、お手軽に可能な「 スポット診断サービス 」 はこちら！ マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp

Prisma Cloudは、クラウド環境のセキュリティとコンプライアンスを一元管理するツールで、リアルタイムの脅威検出やリソースの監視が可能です。今回は、実際にGoogle Cloud環境（プロジェクト）をPrisma Cloudに接続してみました。 作業する前に まずは接続する前に接続方法や前提条件の確認から行います。 接続パターン Azure環境をPrisma Cloudに接続するには、以下の2つのパターンがあります。 1 組織 GCP組織内のすべてのプロジェクトをPrisma Cloudに接続します。 2 プロジェクト 単一のプロジェクトのみを接続します。   接続方法 Prisma CloudにGoogle Cloud環境を接続するためには、Google Cloud環境側で必要なリソースを作成する必要があります。 以下の方法が利用できます。 1 Terraform（推奨） 自動的にPrisma Cloudアプリケーションをセットアップし、プロジェクトへのアクセスを許可します。 2 カスタムロールJSON 手動でカスタムロールを作成し、Prisma Cloudアプリケーションに必要な権限を付与します。   前提条件 サービスアカウントの権限 Prisma CloudがGCPアセットを監視するためには、サービスアカウントに特定の権限を与える必要があります。組織全体での監視を行う場合は、組織のIAMポリシーにロールを割り当てることが必要です。プロジェクト単位での監視も同様に、各プロジェクトのIAMポリシーにロールを設定します。 サービスアカウントに必要な権限は以下の通りです。 Viewer ：基本的な読み取り権限です。 Prisma Cloud Viewer ：クラウドストレージのメタデータを読み取り、IAMポリシーを更新するためのカスタムロールです。 Compute Security Admin（オプション） ：自動修正を有効にする場合にのみ必要なロールです。 Organization Role Viewer（オプション） ：組織全体のオンボーディングに必要です。単一プロジェクトの場合は不要です。 Dataflow Admin（オプション） ：データフローログを圧縮する際場合に使用します。 Folder Viewer（オプション） ：GCPフォルダのメタデータをオンボードし、特定のフォルダを選択し（フォルダを含めるか除外するか）、フォルダ階層に基づいてアカウントグループを自動的に作成する場合にのみ必要なオプションの権限です。 GCP APIのレート制限 Prisma CloudからのAPI呼び出しは、オンボーディングしたGCPプロジェクトのクォータを使用します。そのため、レート制限を超えないように注意が必要です。レート制限エラーを回避するためには以下を確認してください。 作成するサービスアカウントに　serviceusage.services.use　の権限を持たせる メタデータを取得する監視対象のプロジェクトで主要なGCPサービスAPI※を有効化する ※GCP サービス (appengine.googleapis.com、commender.googleapis.com、sqladmin.googleapis.com、apikeys.googleapis.com、iam.googleapis.com、cloudresourcemanager.googleapis.com、orgpolicy.googleapis.com、cloudasset.googleapis.com、accessapproval.googleapis.com is.com、 essentialcontacts.googleapis.com) GCP APIの利用 Prisma Cloudは、さまざまなGCP APIからデータを取り込むことができます。オンボーディングをスムーズに行うためには、必要なAPIを事前に有効にしておくことが重要です。 オンボーディングでPrisma Cloudに用意されているTerraformテンプレートを使用する場合、必要なアクセス許可は自動的に有効になります。 手動でカスタムロールを作成してオンボーディングを行う場合、以下のページを参考に必要なAPIを有効化してください。 ・GCP 組織とプロジェクトをオンボーディングするための前提条件（ https://docs.prismacloud.io/jp/enterprise-edition/content-collections/connect/connect-cloud-accounts/onboard-gcp/prerequisites-to-onboard-gcp ）   接続してみる 前提条件等の確認ができたのでここからは実際に接続してみます。 今回はTerraformを使ってGoogle CloudのプロジェクトをPrisma Cloudに接続します。 作業準備 Google Cloud環境（プロジェクト）とPrisma Cloudの接続作業には、以下の準備が必要です。 プロジェクトIDおよびテナントIDの情報を用意してください。 ネットワークの監視を行いたい場合はフローログの取得は必要となるため、フローログを保管しているストレージバケットの名前を控えておいてください。 接続するプロジェクトに対してPrisma Cloud用のサービスアカウントを追加するため、以下の権限を持っていることを確認してください。 ・サービスアカウント管理者 ・サービスアカウントキー管理者 ・Project IAM 管理者 ・Service Usage 管理者 ・ロールの管理者 Google CloudでCloudShellが使えることを確認してください。 Terraformスクリプトの取得 Prisma Cloudにログインします。 「設定」から「プロバイダ」＞「クラウドアカウント」を選択し、「プロバイダーに接続する」＞「クラウドアカウント」をクリックします。 クラウドプロバイダーで「Google Cloud Platform」を選択します。 「始めましょう」の画面が表示されたら、範囲で「プロジェクト」を選択します。 今回はCSPM機能だけ利用できればよいので、エージェントレスワークロードスキャンやサーバレス機能スキャン、エージェントベースのワークロード保護はチェックを外して次に進みます。 「アカウントの設定」画面が表示されたら、以下を入力します。 ・プロジェクトID ・アカウント名　※自由に指定できます ・「修復」機能は利用しないためチェックを外したままにします ・フローログを有効化したいため「フローログのストレージバケット名」にあらかじめ控えておいたストレージバケット名を入力します ・Dataflowを利用した圧縮ログ生成機能は今回は使用する想定がないためチェックを外したままにします 上記を入力するとTerraformスクリプトがダウンロードできるようになるので、「Terraformスクリプトのダウンロード」をクリックします。   これでTerraformスクリプトのダウンロードは完了です。 Terraformスクリプトの実行 Terraformスクリプトがダウンロードできたので、次はGoogle Cloud環境上でTerraformスクリプトを実行します。 Google Cloudプロジェクトに必要な権限（上記の「前提条件」を参照）を持ったユーザーでログインします。 今回はオーナー権限でログインしました。 CloudShellのアイコンをクリックしてCLI画面を表示します。ここからはCloudShell上での作業になります。 任意のパスにディレクトリを作成して、先ほどダウンロードしたTerraformスクリプトををアップロードします。 作成したディレクトリに移動します。 以下のコマンドを実行します。 # terraform init 「Terraform has been successfully initialized!」と表示されればOK 以下のコマンドを実行します。 # terraform apply 以下のポップアップが表示されたら「承認」をクリックします。 実行するか確認されるので、「 yes 」と入力します。 「Apply complete!」と表示されたら実行完了です。 「Please download the file~」と表示されているjsonファイル名を控えておきます。 前項で名前を控えたファイルをダウンロードをダウンロードします。 Prisma Cloudに接続 Terraformスクリプトを実行して必要なリソースをGoogle Cloud環境に設定できたので、次はいよいよPrisma Cloudに接続します。 Prisma Cloudにログインします。 Terraformスクリプトの取得でプロジェクトID等を入力したところまで同じ設定をして進みます。 「アカウントの設定」画面で、「Terraformスクリプトのダウンロード」の下にある以下の画面で、Terraformスクリプト実行後にダウンロードしたファイルをアップロードします。         ↓アップロードが完了して以下赤枠部分が表示されることを確認します。 「アカウントグループ」の項目で任意のアカウントグループを指定します。 今回は事前に作成しておいたGoogle Cloud環境用のものを指定します。 「Next」をクリックして次の画面に進むと接続が始まります。 レビューステータスがすべて成功（緑色）になれば接続OKです！ 「保存して閉じる」をクリックして完了します。 監視設定してみる AzureサブスクリプションをPrisma Cloudに接続できたので、監視設定をしていきます。 アラートルールの設定 セキュリティ的によくないクラウド設定等を検知するため、アラートルールを設定していきます。 Prisma Cloudコンソール画面上部にある「アラート」を選択します。 「アラートルールを表示」を選択し、「アラートルールの追加」をクリックします。 アラートルール名を入力します。 「ターゲットを割り当て」の画面に進んだら、監視対象のアカウントグループを指定します。 今回は先ほど接続したAzureサブスクリプションで指定したアカウントグループを選択して次に進みます。 「ポリシーを割り当て」の画面に進んだら、監視するポリシーを選択します。 今回は一旦すべてのポリシーで監視してみるので「すべてのポリシーを選択」を有効にして、次に進みます。 「概要」画面に進んだら設定した内容を確認し、「保存」します。 これでアラートルールの設定ができました。 アラート検知 アラートルールを設定してしばらくすると、ポリシーに違反したリソースを検知してPrismaCloudコンソール上にアラートが表示されました。 アセット情報 アラートルールによる監視とは別で、Prisma Cloudに接続されたGoogle Cloudプロジェクトのアセット情報がPrisma Cloudコンソール上で確認できます。こちらは追加の設定等は不要で、Prisma Cloudと接続できれば表示されてきます。 Prisma Cloudコンソール画面上部にある「インベントリ」＞「アセット」を選択すると確認できます。 検証したPrisma Cloud環境は、Google Cloud以外にもAWSやAzureも接続されています。 「GCP」をクリックすると各サービスごとに表示されます。さらに選択していくと、Google Cloud環境上に存在しているリソース情報の詳細を表示することができます。 まとめ 今回は、Prisma CloudにGoogle Cloudプロジェクト接続してアラート検知するところまで確認できました。 今後も、実用的な情報をお届けできればと思います。 また、当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp ご興味のある方は是非、お気軽にお問い合わせください。

こんにちは。今回初めてAzureを触った薮谷です。AWS CloudFormationを利用してAWSのリソースをIaCで構築したことはありましたが、AzureのリソースをIaCで構築したのは初めてでした。 同じOSイメージを使用しAzureVMを複数たてるために、Bicepファイルを使用し、IaCで自動展開することで、設定漏れをなくし、手動で１つずつVMを作成するよりも作業時間を短縮することができます。  AzureはAWSと違い参考になる記事が少なく、経験年数の少ない自分は周りの優秀な先輩に不明点を聞きながら構築を行いました。 Microsoft公式ページにもBicepを使用したVMのIaC構築のやり方は記載がありますが、Azure初心者がこんな感じで構築を行ったというのが別のAzure初心者の方の参考に少しでもなればうれしいです。 はじめに 今回は以下の構成を実現します。 リ ソースグループ/ VNET/サブネットは手動で予め作成した上 で、同じOSイメージを使用した VM1[yabu-vm-1] と VM2[yabu-vm-2] をBicepファイルを使い、デプロイします。 OSはWindows11を使用し、グループポリシーや言語設定などがVM1とVM2にも引き継がれていることがゴールとなります。   １．Bicep拡張機能のインストール IaCのテキストエディタとしてVisual Studioコードを使用します。 未インストールの場合は こちら からインストールしてください。 Visual Studioコードをインストール済の場合は以下➀～④のソフトウェアをインストールしてください。 ➀AzureCLI Bicep の開発およびデプロイ環境のセットアップ – Azure Resource Manager | Microsoft Learn ②Bicep（Bicepコードが正しく作成されていることを検証できる便利ツール） Bicep – Visual Studio Marketplace ③Japanese Language Pack for Visual Studio Code(コメントアウトに日本語を利用できるようになる) https://marketplace.visualstudio.com/items?itemName=MS-CEINTL.vscode-language-pack-ja ④Azure Account(これがないとコードをデプロイできない) Azure Account – Visual Studio Marketplace   2．マスターVMの作成(イメージ準備) マスターVMを手動で作成します。 今回上の図で作成するVM1とVM2のイメージを作成するためにマスターVM(vm-master)を1台作成しますが、こちらのマスターVMは一般化(※後述の手順で説明します）すると起動できなくなってしまいます。 以下に今回行う設定を記述しますが、要件にあった設定を各々行ってください。 ※ 赤字の設定は同じ設定を行ってください。 VMの手動作成方法が不明の場合はこちらを参考に実施してください。 クイック スタート – Azure Portal で Windows VM を作成する – Azure Virtual Machines | Microsoft Learn [基本]タブの設定箇所 ➀ 仮想マシン名：vm-master （マスターVM名、命名は適当で大丈夫です）   ② セキュリティの種類： Standard （こちらを選択しないと今回の手順ではイメージ作成ができなくなります。） 　イメージ： Windows 11 Pro, version 23H2 – x64 Gen 2   ③ ユーザ名、パスワード名：任意の値を設定します [ネットワーク]タブの設定箇所 仮想ネットワーク：作成済の「vnet-yabutani(10.101.0.0/24)」を選択 サブネット：WindowsVMSubnet(今回は10.101.0.0/25のIPで事前作成済)を選択   今回他に設定したい箇所はないので最下部の、「確認および作成」を選択します。 検証に成功しました、の表示を確認し「作成」を選択します。   3．マスターVMのOS設定 Bastionの作成 ➀OSログインのためにBastion経由で接続できるようにします。 作成したマスターVM「vm-master」に移動し、「Bastion」を選択します。   ②「Bastionのデプロイ」を選択します。 ※時間がかかります。数分ほどお待ちください。 Bastionですが使用していなくても1時間あたり課金されてしまうので使用後は削除するのを忘れないでください。 Azure Bastion Basicでも1時間あたり30円課金されてしまうので、注意。 ※画像は2024年7月31日時点のものです。最新の情報は下記URLからご確認ください。 価格 – Azure Bastion | Microsoft Azure   ③VMの作成時、[基本]タブの設定箇所-③で設定したユーザ名/パスワードを入力し、「接続」を選択します。   ④OSログインでき、Windowsのデスクトップ画面が表示されます。 OS設定 今回設定する箇所として、以下3点とします。 ・タイムゾーン ・言語設定 ・グループポリシー ➀タイムゾーン [Setting]-[Time＆Language]-[Date＆time]-[Time zone]へ移動し、「(UTC+09:00)Osaka,Sapporo,Tokyo)」を選択する。 ②言語設定 [Setting]-[Time＆Language]-[Language＆region]へ移動し、「Add a language」を選択する。 検索窓に’ja’と入力すると「日本語」が表示されるので、選択し「Next」を選択する。 [Optional language features]で以下を選択し、「Install」を選択する。 ・Language pack(言語パック) ・Text-to-speech(基本の入力) ※ダウンロードが完了するまで数分かかります。   [Setting]-[Time＆Language]-[Language＆region]へ移動し、[Windows diaplay language]を「日本語」へ変更する。 ③グループポリシー [Local Group Policy Editor（ローカルグループポリシーエディター） ]-[Windows Settings(Windowsの設定)]-[Security Settings(セキュリティの設定)]-[Account Policies(アカウントポリシー)]-[Password Policies(パスワードのポリシー)]へ移動し、以下の要件へ変更する。 ・Minumum password length(パスワードの長さ)：8 ・Minumum password length audit（パスワードの最小文字数の監査）:10   ➀～③の設定が完了した後再起動し、設定が反映されていることを必ず確認してください。 4．マスターVMのSysprep Sysprep（OSの操作） PCそれぞれに割り振られる固有情報を削除し、複数のPCに対して一貫したデータ展開を可能にするためSysprepを行います。 エクスプローラーの「C:\Windows\System32\Sysprep」に移動し、「Sysprep」をダブルクリックします。 シャットダウンオプションにて「シャットダウン」を選択し、「OK」を選択します。 PCの接続が切断されます。   Sysprep（Azureコンソールの操作） CloudshellからVMを一般化します。 Cloudshellを使用するにはストレージアカウントが必要なので、使用できるストレージアカウントがない場合は以下を参考に作成してください。 永続的なストレージを使った Azure Cloud Shell の概要 | Microsoft Learn 以降、既にストレージアカウントを作成済の前提で手順を記載します。 ➀コンソール右上の＞＿のようなマークがCloudshellのターミナルになります。クリックしてCloudshellのターミナルを開いてください。 ②「切り替え先PowerShell」を選択し、BashからPowerShellに切り替えます。 ③PowerShellのターミナルが立ち上がります。少し経つとプロンプトがかえってくるので、以下の一般化コマンドを実行します。 >> Set-AzVm -ResourceGroupName “リソースグループ名” -Name “先ほどSysprepしたVM名” -Generalized 成功するとStatus：Succeededと応答が返ってきます。 ④「最新の状態に更新」をクリックすると、マスターVMが開始できなくなります。 イメージ作成 起動できなくなったマスターVMからイメージを作成します。 ➀[キャプチャ]-[イメージ]を選択します。 ②「Azure コンピューティング ギャラリーにイメージを共有する」を「いいえ、マネージド イメージのみをキャプチャします。」の項目に変更して「確認および作成」を選択します。 ③「検証に成功しました」と表示されたことを確認し「作成」を選択します。 ④通知に「仮想マシンが一般化されました」という表示がされます。これで一般化が完了したことがわかります。 「リソースに移動」を選択します。 ⑤[設定]-[プロパティ]に移動し、「リソースID」をコピーします。 こちらでコピーしたリソースIDを使用し、この後イメージをBicepで展開していきます。 5．Bicepファイルを使用したVMの展開※対象：yabu-vm-1 ※対象：yabu-vm-1 Bicepを用いてマスターVMのイメージからVM1[vm-yabu-1]とVM2[vm-yabu-2]をデプロイします。 VM作成に必要なBicepはMSの公式ページを参考にしてください。 クイックスタート: Bicep ファイルを使用した Windows VM の作成 – Azure Virtual Machines | Microsoft Learn 今回は以下のコードを使用します。 ➀作成するリソースを記載したmain_test.bicep ②各リソース内の変数をパラメータとして外だしし記載したtest.bicepparam ➀main_test.bicepを記述（エディター：Visual Studio Code） // targetScope = ‘resourceGroup’ // リソースグループ(デフォルト）レベルでデプロイする場合は省略可   // 全般設定 param location string = ‘japaneast’ // デプロイするリージョン   // VMの設定 param vmName string // VMの名前 param adminUsername string // VMの管理者ユーザー名 @secure() param adminPassword string // VMの管理者パスワード   param vmSize string // VMのサイズ param vmHostName string   param osDiskName string // OSディスク名 param osDiskSize int //OSディスクのサイズ param osDiskType string // OSディスクの種類   param customImageId string // カスタムイメージのリソースID   // ネットワークインターフェースの設定 param nicName string //NIC名 param nicPrivateIP string //指定したいプライベートIPアドレス param ipConfigName string //IP構成名   // 参照する既存リソース param existingVnetName string // 既存VNet param existingSubnetName string // 既存サブネット param existingRgName string // 参照する既存リソースの所属リソースグループ   //参照する既存リソース resource existingVnet ‘Microsoft.Network/virtualNetworks@2023-06-01’ existing = {   name: existingVnetName   scope: resourceGroup(existingRgName) }   resource existingSubnet ‘Microsoft.Network/virtualNetworks/subnets@2023-06-01’ existing = {   name: existingSubnetName   parent: existingVnet }     // ネットワークインターフェースのリソース resource networkInterface ‘Microsoft.Network/networkInterfaces@2023-06-01’ = {   name: nicName   location: location   properties: {     ipConfigurations: [       {         name: ipConfigName         properties: {           subnet: {             id: existingSubnet.id           }           privateIPAllocationMethod: ‘Static’           privateIPAddress: nicPrivateIP         }       }     ]   } }   // 仮想マシンのリソース resource virtualMachine ‘Microsoft.Compute/virtualMachines@2023-09-01’ = {   name: vmName   location: location   zones: [‘1’]   properties: {     hardwareProfile: {       vmSize: vmSize     }     osProfile: {       computerName: vmHostName       adminUsername: adminUsername       adminPassword: adminPassword       windowsConfiguration: {         enableAutomaticUpdates: false       }     }     storageProfile: {       imageReference: {         id: customImageId // カスタムイメージを使用する場合に使用。       }          // OSディスクの設定       osDisk: {         name: osDiskName         createOption: ‘FromImage’         diskSizeGB: osDiskSize         managedDisk: {           storageAccountType: osDiskType         }       }     }     networkProfile: {       networkInterfaces: [         {           id: networkInterface.id         }       ]     }   } }     ②test.bicepparamを記述（エディター：Visual Studio Code） using ‘./main_test.bicep’ //ここでmain_test.bicepを参照している記述を記載   // 全般設定 param location = ‘Japan East’ // デプロイするリージョン   // VMの設定 param vmName = ‘yabu-vm-1’ // VMの名前(VMごとに変更) param adminUsername = ‘azureuser’ // VMの管理者ユーザー名 param adminPassword = ‘abcdefg’ // VMの管理者パスワード param vmSize = ‘Standard_F4s_v2’ // VMのサイズ(VMごとに変更) param vmHostName = ‘yabu-vm-1’     param osDiskName = ‘osdisk-yabu-name’ // OSディスク名(VMごとに変更) param osDiskSize = 127 //OSディスクのサイズ(VMごとに変更) param osDiskType = ‘StandardSSD_LRS’ // OSディスクの種類     // カスタムイメージのリソースID param customImageId =’サブスクリプションID/resourceGroups/rg-technologyservice-1/providers/Microsoft.Compute/images/vm-master-image-20240801154224′ //4-⑤でコピーしたイメージのリソースIDを記載する   // ネットワークインターフェースの設定 param nicName = ‘nic-yabu-name’ //NIC名(VMごとに変更) param nicPrivateIP = ‘10.101.0.11’ //指定したいプライベートIPアドレス(VMごとに変更) param ipConfigName = ‘Ipconfig-name’ //IP構成名     // 参照する既存リソース param existingVnetName = ‘vnet-yabutani’ // 既存VNet(事前手動作成) param existingSubnetName = ‘WindowsVMSubnet’ // 既存サブネット(事前手動作成) param existingRgName = ‘rg-technologyservice-1’ // 参照する既存リソースの所属リソースグループ(事前手動作成)   ③それぞれのファイルをエクスプローラーの同じフォルダ内に配置し、VisualStudioCodeからファイルを開く ④コード右上の表示される雲マークをクリックします。 test.bicepparamのファイルから選択してください。 ⑤[Deploy]をクリックします。 画面では前回リプレイスした際の情報（サブスクリプション、リソースグループ）が残っていますが、初めてデプロイする場合はAzureサインインを求められます。Azureテナントにサインインした上でVMをデプロイしたいサブスクリプション、リソースグループを選択してください。 ⑥デプロイ成功 RESULT：Succeededと帰ってきたらyabu-vm-1のデプロイ成功です。 6．Bicepファイルを使用したVMの展開※対象：yabu-vm-2 ※対象：yabu-vm-2 ➀test.bicepparamを記述（エディター：Visual Studio Code） yabu-vm-1をデプロイした際に使用したコードをそのまま流用します。test.bicepparamファイルはyabu-vm-1と2で分けて記載した方が良いです。書き換えている部分だけ赤字にしています。 ※main_test.bicepファイルの内容は変更しません。 using ‘./main_test.bicep’ //ここでmain_test.bicepを参照している記述を記載   // 全般設定 param location = ‘Japan East’ // デプロイするリージョン   // VMの設定 param vmName = ‘yabu-vm- 2 ‘ // VMの名前(VMごとに変更) param adminUsername = ‘azureuser’ // VMの管理者ユーザー名 param adminPassword = ‘abcdefg’ // VMの管理者パスワード param vmSize = ‘Standard_F4s_v2’ // VMのサイズ(VMごとに変更) param vmHostName = ‘yabu-vm- 2 ‘     param osDiskName = ‘osdisk-yabu-name- 2 ‘ // OSディスク名(VMごとに変更) param osDiskSize = 127 //OSディスクのサイズ(VMごとに変更) param osDiskType = ‘StandardSSD_LRS’ // OSディスクの種類     // カスタムイメージのリソースID param customImageId =’サブスクリプションID/resourceGroups/rg-technologyservice-1/providers/Microsoft.Compute/images/vm-master-image-20240801154224′ //4-⑤でコピーしたイメージのリソースIDを記載する   // ネットワークインターフェースの設定 param nicName = ‘nic-yabu-name 2 ‘ //NIC名(VMごとに変更) param nicPrivateIP = ‘10.101.0.1 2 ‘ //指定したいプライベートIPアドレス(VMごとに変更) param ipConfigName = ‘Ipconfig-name -2 ‘ //IP構成名     // 参照する既存リソース param existingVnetName = ‘vnet-yabutani’ // 既存VNet(事前手動作成) param existingSubnetName = ‘WindowsVMSubnet’ // 既存サブネット(事前手動作成) param existingRgName = ‘rg-technologyservice-1’ // 参照する既存リソースの所属リソースグループ(事前手動作成)   コードを書き換えたら、yabu-vm-1と同様の手順（5-③～⑤の手順）を再度実行してyabu-vm-2をデプロイしてください。 ②コンソール画面での確認 yabu-vm-1とyabu-vm-2がそれぞれ指定したリソースグループ、サイズ、OS、プライベートIP、VNETにて作成されていることを確認できました。 ※コンピュータ名についてはマスターVM(vm-master)の名前が引き継がれてしまいます。OSログインした上でホスト名を手動で任意の名前に変更してください。 7．Bicepファイルを使用したVMにOS設定が複製されているか確認する 3.マスターVMのOS設定にてvm-masterに設定したOSの設定がyabu-vm-1とyabu-vm-2に引き継がれているか確認します。 ※今回はyabu-vm-1のみの確認となります。 3-③の手順同様[VM]-[接続]-[Bastion]からyabu-vm-1のBicepで指定したユーザ名とパスワードを入力し、Bastion経由でyabu-vm-1のOSにログインします。 ➀タイムゾーン： ②言語設定 ・Language pack(言語パック) ・Text-to-speech(基本の入力) がインストールされており、表示も日本語の状態でデプロイされている。   ③グループポリシー ・パスワードの長さ：8文字以上 ・パスワードの最小文字数の監査:10文字 上記設定がマスターVM(vm-master)から引き継がれて、他のポリシーはデフォルトのままであることを確認できている。   おわりに 同じOSイメージを使用した VM1[yabu-vm-1] と VM2[yabu-vm-2] をBicepファイルを使い、デプロイすることができました。 マスターVMで設定したOSの各種設定（タイムゾーン/言語設定/グループポリシー)がVM1とVM2にも引き継がれていることを確認することができました。

こんにちは。SCSK の樋口です。 デジタルイノベーションの総合展『CEATEC 2024』が、今年も千葉県の幕張メッセで開催されています。 CEATEC（シーテック） は日本最大級の展示会として有名で、2024年の今年は、10月15日（火）～18日（金）の計4日間、国内外から808もの団体が、先進技術やイノベーションの種を展示しています。 実は、当社SCSKも、CEATEC にブースを出展しています。 そして、この私が CEATEC の出展リーダーをしています。 この記事では、CEATEC 2024 における SCSK ブースの概要について、現地から速報でお届けいたします。 「現場レポート動画」も作りました。 SCSK ブースの様子を、動画でもご理解いただけます。                         CEATEC の様子 とにかく会場が大きいです。 ホール3から8まで、実質6ホールがCEATECの会場で、端から端まで歩くだけでも時間がかかります。 加えて、併設の「Japan Mobility Show Bizweek」も加えると、ホール1から8までの展示会となり、幕張メッセの会場全てが CEATEC とも言えるような状況です。   SCSK ブースの様子 SCSK のブースは、ホール3-016 にあります。 横幅が9メートルあり、CEATEC全体の中では中規模なブースです。 大きな通路に面した分かりやすい場所にあるのが、個人的にポイント高いです。 お客さんが来てくれるかどうか、準備段階ではとてもヒヤヒヤしていたのですが、 いざ始まってみると、 朝10時の開場からSCSKブースは大盛況で、リーダーの私は感激しています。     SCSK の出展内容 SCSK のブースでは、製造業のお客様向けに、 製造現場におけるデータの「収集」「可視化」「分析」そして「異常検知」を支援するソリューションの「Duetics（デュエティクス）」を紹介 しています。 各機能について、コーナーごとに分けて詳しく紹介をしています。 分析コーナー：多変量解析アプリケーション 製造現場で発生するデータを分析するのが、「多変量解析アプリケーション」です。 工場にあるPLCやセンサーのデータを分析することで、不良品の原因や機器の故障原因を特定し、生産性の向上と品質改善につなげることができます。 CEATECでは、製造現場を再現したミニチュア工場を動かしながら、データの取得、可視化、分析のデモンストレーションを行い、生成AIを実装した分析機能もご紹介しています。 詳しくはこちら： https://www.scsk.jp/product/common/duetics/index.html   可視化コーナー：製造業デジタルツイン 製品や工場全体を、デジタル空間上で精緻に再現するのが、「製造業デジタルツイン」です。 デジタルツインを作ることで、仮想空間上で様々な検証を行うことができるので、現実世界での製造ラインの立ち上げや切り替えを早めることなどが可能です。 CEATECでは、物理的なミニチュア工場と、バーチャル空間上に構築したデジタルツイン工場との連携をお見せすることで、お客さんに具体的な活用イメージを提供しています。 詳しくはこちら： https://www.scsk.jp/sp/nvidia/omniverse/index.html 収集コーナー：自律分散型 IoT ネットワーク IoT機器向けの自律分散型ネットワーク技術が「CollaboView」です。 SCSKグループの Skeed 社が持つP2P通信技術を用いて、製造機器のデータを、低電力かつ効率的に、障害にも強い方法で収集する技術です。 CEATEC では、人感センサーで人を検知すると、CollaboView のネットワークを経由してサーバに情報を送信し、パトランプを光らせるデモンストレーションを実施しています。 詳しくはこちら： https://collaboview.scsk.jp/ 異常検知コーナー：異常検知ソリューション 設備の故障予兆や不良品の検出に使えるのが、製造業向けの「異常検知ソリューション」です。 様々な機能を搭載しており、面白いものだと、工場作業員の作業工程の動画から、組み立て手順のミスを見つける。といったことも可能です。 詳しくはこちら： https://www.scsk.jp/news/2024/pdf/20240927.pdf 最後に & お問い合わせ先 この記事では、CEATEC 2024 が開催中の幕張メッセから、SCSK ブースの出展内容を速報でご紹介いたしました。 会場全体がものすごい熱気ですが、当社 SCSK の担当者たちも、ほぼフル回転でお客さん対応にあたっています。 詳しい話を聞きたいと思った際には、ぜひ幕張メッセのホール3-016 SCSKブースまで足をお運びください。 また、以下のメールアドレスからお問い合わせをいただいても構いません。（TechHarmony の記事を見た。と記載ください。） SCSK 株式会社  Duetics 担当 duetics-sales@scsk.jp 最後まで読んでいただき、ありがとうございました。 ※ 本記事の内容は、CEATEC 2024 の Day2 と Day3 に基づきます。今後変更が発生する可能性もございます。 #SCSK は #CEATEC 2024 に出展しています。 製造業向けの、デジタル化ソリューションを紹介中！ 10月18日（金）まで。幕張メッセ　ホール3-016でお待ちしております！ @umeno_senri @moe_hoshino https://t.co/xGQXCjG1rY pic.twitter.com/Fv4wolys3B — SCSKクラウドソリューション【公式】 (@SCSK_Cloud) October 17, 2024  

これからCatoクラウドが新たに導入予定の「自然言語検索によるイベントフィルタリング」機能を、先行して使ってみました。 ・ 自然言語検索(EA)によるイベントのフィルタリング この機能は、複雑なクエリやコマンドを使わずに、日常の言葉でイベントデータを検索できるというものです。 これまでの検索方法は、自分で適切なフィルタを決める必要がありました。 用意されているフィルタの数は膨大で、いったいどれを指定すればよいのか、一度は迷ったことがあるのではないでしょうか。 新機能では、検索バーに自然言語でクエリを入力すると、AIエンジンがそのクエリをフィルタに変換し、関連するイベントデータを表示します。 なお、今回利用した段階では日本語未対応でしたが、今後の機能追加が予定されています。 今回の利用では、ユーザが実際に入力しそうな日本語を DeepL で英語翻訳した結果を、そのままコピペして試しています。 それでは、この新機能の使い方や実際に試してみた結果について詳しく紹介していきます。 使い方 使い方は簡単で、フィルタを入力する欄の右端🔍虫眼鏡アイコンをクリックすると、文字が入力できるようになります。 ここで表示したいログを指示します。 試してみる それでは、実際に試してみます。 Cato社紹介のユースケースから まずはCato社の 新機能紹介ページ で説明されているユースケースの通りに入力してみて、想定通り動作するか見てみます。 今回は2パターン見てみました。 ゲームカテゴリの URL からのインターネットファイアウォールのセキュリティイベントを表示する 「Show me Internet Firewall security events from game category URLs」 【フィルタ結果】 Event Type：Security Sub Type：Internet Firewall Category：Games 続いて2つめ。 アプリケーションの脆弱性と脅威に関連する最近のセキュリティインシデントとアラートを表示する 「Show recent security incidents alerts related to anti-malware」 【フィルタ結果】 Event Type：Security Sub Type：Anti Malware 結果として、Cato社が紹介している例ということもあり、問題なく2例とも想定通りのフィルタがかかりました。 また、文字を入力してから、フィルタが決定されるまで体感1秒程度でした。 手動でフィルタするよりも明らかに早く、利便性がかなり高いと言えます。 エンドユーザ目線で ここからは、実際にいただいたお問い合わせをもとに、私自身でユースケースを考えてみました。 色々と日本語・英語をチューニングして試しています。 あるユーザが特定のサイトへアクセスできない 私(なかがわ きょうすけ)が、任天堂のサイトへアクセスしてブロックされた結果を表示できるか試してみます。 中川さんが任天堂のサイトが見られなくて困っている。見られない。 「Mr. Nakagawa is having trouble viewing Nintendo’s website.」 「Mr. Nakagawa can’t see Nintendo’s website.」 結果はフィルタできず。フィルタ指定に失敗すると以下のエラーになる。 「 Error – unsupported filters The search engine returned a response, but your request uses unsupported filters and can’t be displayed. Please check the filters and try again.」  あまりに口語的な表現をすると、失敗してしまうようです。 次に、Cato社の紹介例のように、ログが見たいという意図を伝えてみます。 中川さんが任天堂のサイトにアクセスできなかったので、そのログが見たい。 「Mr. Nakagawa accessed Nintendo’s website and would like to see the blocked logs.」 【フィルタ結果】 Action：Block Domain Name：nintendo.com フィルタはかかるが、ユーザ指定するには情報が足りないのかフィルタできず。 ドメイン名はフィルタされたが、 www. nintendo.comのログが見たいため不十分。 今度は、ユーザ名とドメイン名を正確に入力してみる。 中川恭介さんのwww.nintendo.comのドメインでブロックされたログが見たい。 「I would like to see the log of Kyosuke Nakagawa’s www.nintendo.com being blocked.」 【フィルタ結果】 Domain Name：www.nintendo.com Action：Block User Display Name：Kyosuke Nakagawa ようやく、満足のいく結果に。 まだ正確な情報で入力する必要があり、”よしなに”フィルタをかけることは難しそうです。 日時指定でブロックされたログが見たい 今度は日時指定ができるか試してみます。 10月2日にブロックされたイベントが見たい。 「I would like to see an event blocked communication in 2nd October.」 【フィルタ結果】 Action：Block 日時指定：10/2 0:00~23:59 右上の日時指定が更新され、アクションもきちんとブロックで指定されました。 今度は、少し表現を複雑に変えてみます。 10/2の午前中にブロックされたイベントが見たい。 「I would like to see an event on the morning of 10/2 with blocked communication.」 【フィルタ結果】 Action：Block 日時指定：10/2 0:00~12:00 「2nd October」を「10/2」に変更し、午前中という表現も加えてみましたが、きちんとフィルタされました。 日時指定の表現はいくらか融通が利きそうです。 あるアプリの操作をブロックしているログを見たい 最後に、セキュリティオプションのCASB機能でブロックされたログが見られるか、確かめてみたいと思います。 今回は、Gmailにてファイル添付をブロックしているログを見てみたいと思います。 結果として、一筋縄ではフィルタされず、色々と表現を変えながら試すこととなりました。 まずは、以下に失敗したスクリプトをご紹介します。 ファイル添付がブロックされた / できなかったログが見たい 「I would like to see a log of blocked file attachments in Gmail.」 「I would like to see a log of files that could not be attached in Gmail.」               Gmailアプリのファイル添付に関するログが見たい 「I want to see logs about file attachments in the application “Gmail”.」 Gmailに関するログが見たい 「I want to see logs about Gmail.」 「I want to see logs with application name Gmail.」 ここで、「Gmailに関するログが見たい」という単純な表現に変えても出力されず。 Gmailという表現をここであきらめて、Googleに広げて聞いてみました。 Googleに関連するアプリケーションのログが見たい。 「I would like to see logs of google related applications.」 【フィルタ結果】 Application：Google Drive、Google ようやくフィルタがかかりましたが、Google DriveとGoogleのみで、なぜかGmailは含まれませんでした。 英語の表現が適切でないと感じ、Gmail に関する(about,with) ではなく、Gmail 上(on) のログという表現に変えてみました。 Gmailアプリ上でブロックされたログが見たい 「I would like to see the blocked logs on the gmail application.」 【フィルタ結果】 Action：Block Application：Gmail すると、ようやく、Gmailでブロックされたログにフィルタされました。 続いて、ファイル添付がブロックされたログが見られないか、スクリプトを考えていきます。 Gmailアプリ上で、ファイル添付がブロックされたログが見たい 「I would like to see a log of blocked file attachments on the gmail application.」 【フィルタ結果】 Action：Block Application：Gmail ファイル添付はくみ取ってもらえず、「Gmailでブロック」のフィルタのみとなりました。 次に、Gmailは一旦あきらめて、イベントフィールドの値を「ファイル添付」で指定するようなスクリプトにしてみます。 アプリケーションアクティビティがファイル追加のログが見たい I would like to see a log of the application activity add attachment.× 残念ながらエラーの結果に。。 他にも色々と表現を変えながら試しましたが、「ファイル添付」でフィルタしてもらうことは出来ませんでした。。 諦めようとしたその時、気づきました。 新機能紹介ページ によると、そもそもApp Activityが今後追加予定のフィールドになっていることに。。 想定していた全てのフィルタを設定することはできず、残念でしたが、 自然言語では未対応のフィルタとわかったため、気持ちよくあきらめることができました。 また、その他の注意点として、同じスクリプトを入力しても、時間を空けるとフィルタの結果が変わったり、場合によってはフィルタ出来なくなったりすることがあります。 【補足】単語のみでフィルタ可能か？ ちなみにですが、以下のように、文ではなく単語の列挙に近い記載でフィルタできるかも試してみましたが、結果はあまり芳しくありませんでした。 最低限、所有の’s や前置詞は記載する必要があるようです。 検索ワード フィルタ結果 Block × block event 〇 Action：Block IPS 〇 sub-type：IPS sub-typeに登録されているキーワードであれば、単語のみの検索でも比較的表示されました。 today ips block 〇 日時：当日午前0時から現在時刻 Event-Type：Security sub-type：IPS Action：Block today nakagawa block× × today’s nakagawa block event × today’s block event of Nakagawa 〇 日時：当日午前0時から現在時刻 User Name：Nakagawa Action：Block Kyosuke Nakagawa www.nintendo.com Block × Kyosuke Nakagawa’s Block event to www.nintendo.com 〇 User Name：Kyosuke Nakagawa Action：Block Domain Name：www.nintendo.com   まとめ 率直に、予想していたよりもフィルタを効かせることはできるな、という感想を持ちました。 ただし、生成AIのチャットボットを利用する際も同様ですが、スクリプトにはコツが要ります。 慣れるまでは、今まで通り手動でフィルタする方が早いかと思います。 今後、Cato内のAIが学習を進め、ラフな自然言語でも読み解いてくれて、 上手くフィルタしてくれるようになるまで成長してくれるといいです。

はじめに 今回はPrisma CloudのCWPP領域のセキュリティ機能であるランタイム防御(Runtime Defense)でLambda関数を監視し、 許可していないプロセスの起動を拒否してみようと思います。 そもそものCWPPについて知りたい方は弊社、鎌田の以下記事が参考になると思います。 Prisma Cloud の主要機能の１つ CWPP のアーキテクチャを解説 また、ランタイム防御を設定するためには、事前にLambda関数にディフェンダー(エージェントのようなもの)を導入する必要があります。 本記事ではディフェンダーがLambda関数に導入済みである前提で、導入手順については記載しません。 ディフェンダーの導入手順については弊社、渡邊の以下記事が参考になると思います。 【CWPP】Prisma Cloud のサーバーレスディフェンダーの導入方法 本記事はPrisma Cloudのランタイム防御に関する以下公式ドキュメントを参考に作成します。 Runtime Defense for Serverless Functions (prismacloud.io)   ランタイム防御でできること ランタイム防御では、コンテナに対する予測的保護と、実行中のコンテナ、ホスト、サーバーレス機能に対する脅威からの保護を提供しています。 予測的保護は、コンテナが元のイメージに含まれていないプロセスを実行したり、予期せぬネットワークソケットを作成したりする際に、それを検出してくれます。 脅威からの保護は、ワークロードにマルウェアが追加された場合や、ワークロードがボットネットに接続する場合に、それを検出してくれます。 ランタイム防御では検出以外にも、プロセス、ネットワーク、ファイルシステムにおけるアクティビティを許可、拒否することができます。 本記事では実際に、ランタイム防御でLambda関数のプロセスのアクティビティを拒否してみます。   サーバレスランタイムポリシー まずは、サーバレスランタイムポリシーを作成します。 本ポリシーでランタイム防御で利用する機能や防御対象とするLambda関数などを指定します。 「Defend > Runtime > Serverless policy」を開き、「Add rule」をクリックします。 ポリシーのルール画面が表示されます。 Scopeではランタイム防御の対象を設定することができます。この対象をcollectionと呼びます。 Scopeの「Click to select collections」をクリックします。   collectionを選択して、「Select collections」をクリックします。 今回は既に作成していたcollectionを選択しますが、右上「Add collection」で新たにcollectionを作成することもできます。   ポリシーを作成できたので、ここからはランタイム防御でプロセスのアクティビティを拒否してみます。   許可していないプロセスの起動を拒否 それでは、許可していないプロセスがLambda内で起動するのを拒否してみます。 実行するプログラムはPythonのsubprocessモジュールを使って、「ls -l」コマンドを実行するプロセスをLambda内に立ち上げ、その結果を返すプログラムとなります。 ランタイム防御の適用前にプログラムを実行すると以下が出力されます。 ポリシーは以下設定とします。Lambda内でPythonプロセス以外はプロセスが立ち上がらない設定としました。 ポリシーを保存した後、TW_POLICY環境変数を取得し、Lambdaに設定することでポリシーが適用されます。 ※TW_POLICY環境変数の取得方法は弊社渡邊の以下記事に記載があります。 【CWPP】Prisma Cloud のサーバーレスディフェンダーの導入方法 Lambdaを実行したところ失敗し、「ls -l」コマンドを実行するプロセスが立ち上がらなかったことが分かります。   検知結果の確認 ランタイム防御でポリシー違反をおこしたリソースを確認できます。 「Monitor > Events」を開き、検知行をクリックすると検知の詳細が表示されます。   まとめ 本記事では、Prisma CloudのCWPP領域のランタイム防御(Runtime Defense)でLambda関数を監視し、 許可していないプロセスを拒否してみました。本記事でPrisma Cloudを利用することのメリットが伝わりましたら幸いです。 また当社ではPrisma Cloud利用して、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 https://www.scsk.jp/sp/cloud_diag/ ご興味のある方は是非、お気軽にお問い合わせください。

こんにちは。SCSK 中山です。   今回はちょっとニッチな記事にはなりますが、CatoクラウドのStand-alone Countries(単独で価格設定されている国)である、中国/ベトナム/モロッコのサイトをご利用の方向けにライセンス毎の帯域利用量を確認する方法を記事として書きたいと思います。 一応、中国/ベトナム/モロッコのサイトをご利用の方向けではありますが、他にも応用が利くかもしれない内容ではあるので、使っていない方も記事を読んでいただけると幸いです。   その前に何故中国/ベトナム/モロッコのStand-alone Countriesに限った話をしているかというと、 通常、Catoではライセンスをサイトごとに帯域のライセンスを提供しておりますが、中国/ベトナム/モロッコに限っては国内/国外の通信ごとでライセンス(Regional/Global)に分かれており、1つのサイトでもRegional/Globalのライセンスを契約する必要があります。そのため普通にCatoを使って通信をしていても、この通信はRegionalのライセンス側の帯域を利用していて、あの通信はGlobalのライセンスを使っているということが起こります。 これだけなら問題ないのですが、通信が遅い等でライセンスごとの帯域の利用量を確認しようとすると、現在(2024/9月時点)のCatoの機能では直接ライセンスごとの帯域使用量を確認できないため、チューニングが難しい状況です。 そこで、ちょっと工夫して事前に設定を行うことで各ライセンスごとに確認することができるようになるため、今回はその方法を紹介したいと思います。   通信要件の整理 設定・確認方法に行く前に通信要件を整理したいと思います。 お客様ごとに通信要件は異なるかと思いますが、一旦、日本拠点が1つとベトナム拠点が2つのみ設定しているという想定で記載したいと思います。 先程、国内/国外でごとでライセンスが分かれると記載しましたが、正確に言うと国内/国外の判定はどこの国へ通信するかではなく、どこのPoPから出ていくかで決まります。 そのため、様々な通信があるかと思いますが、Regional/Global Licenseの観点で整理すると、基本的には以下の①～③になるかと思います。加えて何かの要件で別のPoPから出ていく必要がある場合には、④も発生するという具合になります。 ①ベトナムサイト⇒ベトナムサイト ②ベトナムサイト⇒日本サイト ③ベトナムサイト⇒Internet(ベトナムPoP) (④ベトナムサイト⇒Internet(その他PoP))   上記①～④のうち、①③にRegional License、②④にGlobal Licenseが適用されます。 ※ここではベトナム想定で記載をしておりますが、中国でサイトを作成する場合も同様のライセンス形態をとっており、中国の場合はGreat Firewallがある関係でGoogleアプリ等を利用する際には別PoPからアクセスする必要があるため、中国の場合には④も必須かもしれません。   事前設定 通信要件が整理できたので、事前設定をしていきたいと思います。 今回設定する内容はBand widthのPriorityをタグのように設定し、通信要件で整理した①～④をRegional/GlobalのLicenseごとにNetwork RuleでBand widthのPriority割り振っていくという内容になります。 1.CMAより、「Network」>「Bandwidth Management」を開き、新規で2つRegional/Global License用の「Priority」を作成します。   各サイトのRegional/Globalのライセンス分Priorityの割り当てを行う必要があるので、今回は以下のように4つ設定し、それぞれ用途に合うように割り当てをしていきたいと思います。 P50 ：ベトナムサイトA/Regional P60 ：ベトナムサイトA/Global P70 ：ベトナムサイトB/Regional P80 ：ベトナムサイトB/Global        ※ベトナムサイトBの設定については、ベトナムサイトAと手順が同様のため以降の手順では割愛します。 2.「Network」>「Network Rules」を開き、1サイトにつき以下3つのルールを作成します。(④がある場合には4つ作成します。) 用途 ①ベトナムサイト ⇒ベトナムサイト (サイトA⇒サイトB) ②ベトナムサイト ⇒日本サイト ③ベトナムサイト ⇒Internet(ベトナムPoP) ④ベトナムサイト⇒Internet(その他PoP) Type WAN WAN Internet Internet Source ベトナムサイトA ベトナムサイトA ベトナムサイトA ベトナムサイト Destination ベトナムサイトB Any Any <要件次第> Bandwidth Priority P50 P60 P50 P60 これで設定自体は完了になります。 この設定を行ったことで、設定したサイトのRegionalの通信は P50 、Globalの通信は P60 に集約することができました。   トラフィックの確認方法 Regional/Globalの通信をP50/P60に割り当てしましたので、P50/P60のトラフィックを確認することで、各サイトのRegional/Globalのトラフィックを確認します。   1.「Network」>「Sites」より、確認したいサイトをクリックします。   2.左ペインより「Priority Analyzer」をクリックします。   3.上記で設定したPriorityを展開しますと、選択した期間に通信が発生している場合、トラフィックがグラフで確認できます。   ※選択した期間内に通信が発生しているのにも関わらず、表示されない場合は別のNetwork Ruleによって割り振りがされていない可能性があります。その場合にはEvent等を確認し、どのルールが適用されているか確認し、調整する必要があります。   まとめ 今回はベトナム/中国サイトのトラフィックの見方についてご紹介いたしました。 現時点、きちんと中国/ベトナム/モロッコサイトも帯域の管理をしようとすると、今回紹介した方法くらいしかないと思いますので、ご利用の方は検討してみては如何でしょうか。 ただし、Network Ruleを変更することもあり、既存の通信にも影響が出かねないので、変更にあたっては十分注意していただくようお願いいたします。

こんにちは、SCSKの吉田です。 今年もServiceNow社の年次イベント「 ServiceNow World Forum Tokyo 2024 」が開催されます。 当社はGoldスポンサーとしてブース出展しますので、ご案内いたします！ 開催日：2024年10月15日（火）-10月16日（水） 会場：ザ・プリンスパークタワー東京 イベント内容：基調講演、事例セッション、パートナー企業による展示ブースなど イベントの詳細、参加登録は以下をご確認ください。 ServiceNow World Forum Tokyo 2024 SCSKブースのご紹介 SCSKのブースでは、ServiceNowの ESG・GRCソリューションの紹介や機能デモ を実施いたします。 ESG（環境・社会・ガバナンス）・GRC（ガバナンス・リスク・コンプライアンス）ソリューションは企業のESGの取り組みとリスクを、効率的に管理、追跡、報告するための強力なツールです。 2027年に見込まれるESGやGRCなどサステナビリティ情報の開示義務化、企業のグルーバル化やDX等により出現した多種多様なリスクの管理、法規制強化への対応など、企業のサステナビリティ経営を取り巻く状況は大きく変化しています。 そのため、企業にはこれら環境の変化に迅速に対応しつつ、サステナビリティ経営を推進することで、持続可能なビジネス成長を実現することが求められます。 SCSKでは、大規模・グルーバルでの導入実績、導入から運用改善までのフルラインアップにより、お客様の要件に合わせた最適なESG・GRCソリューションを提供します。 以下に該当する方は是非、当社ブースにお立ち寄りください！ ESG、GRCなどサステナビリティ情報の収集・管理が何故企業にとって重要なのか知りたい方 サステナビリティ経営に関わる業務にお悩みを抱えている方 ServiceNowのESG、GRCソリューションに興味を持っている、導入を検討している方 また、当社ではESGやGRC以外のServiceNowソリューションも多く扱っておりますので、お気軽にご相談ください。 詳細は以下HPをご参考ください。 ServiceNow ServiceNowは、企業の生産性向上や業務プロセス改善を支えるサービスマネジメントクラウドソリューションです。従業員満足度・顧客満足度の向上、業務効率化を強力に支援します。 www.scsk.jp

Catoでは、モバイルユーザ用に用意されたアドレスレンジの中から動的にモバイル端末にアドレスを割り振ることによりモバイル接続が可能となります。そのモバイルユーザ用に用意されたアドレスレンジはデフォルトで10.41.0.0/16に設定されています。 つまり、デフォルト設定のままモバイルユーザがCatoクラウドに接続をすると10.41.0.0/16の中からランダムにアドレスが割り当てられます。実際に試してみると10.41.0.0/16の中から10.41.17.227が割り当てられました。 デフォルトではこのように動的な割り当てになっていますが、ある特定のユーザに対して固定IPを割り当てることができるので今回はその設定方法や注意点についてまとめていきます。 設定上の注意点 設定するにあたり注意点があるので先にお伝えします。 固定IPを割り当てる場合は 動的IPレンジ (デフォルト設定：10.41.0.0/16) と は重複しないようにアドレスを設定する必要がある 点に注意が必要です。 また、Catoでは1ユーザアカウントで3台まで同時接続が可能ですが、 固定IPは1ユーザアカウントに対して1つだけ 割り当てられます。そのため、2台同時接続した場合は片方の端末には動的IPレンジからの割り当てになります。 では、上記を踏まえて実際に設定および動作確認をしてみます。 固定IPの利用シーン 固定IPは通常、ヘルプデスクがリモートデスクトッププロトコル（RDP）を使用してユーザーの端末にアクセスする際や、共有フォルダへのアクセスが必要な場合に主に利用されますよね。 他にも、古い セキュリティ制御システム（Firewall）をご利用されていてIPアドレスで制御する必要がある場合などでも使われているかもしれません。 Catoでも同じ用途で利用します。 今回は、ヘルプデスクがRDPを使用してユーザーAの端末にアクセスするというシナリオで、ユーザAに固定IP 192.168.2.1を割り当て、接続を試してみました。 設定方法 まず2つの端末にCatoクライアントをインストールし、それぞれCatoクラウドに接続をさせます。 ※この手順は長くなるので割愛しますが、ご不明な方はこちらの記事をご参照ください。 Catoクラウド はじめの一歩 次に、ユーザAに対して固定IPを割り当てていきます。 設定箇所はAccess＞IP Allocation Policyです。 手順は以下の通りです。 有効化 デフォルトでは無効になっているので、有効化します。 アドレスレンジの設定 今回の例の場合は、192.168.2.0/24を設定します。 アドレスの割り当て 対象のユーザをプルダウンで選択し、先ほど設定したアドレスレンジ(192.168.2.0/24)の中から1つアドレスを割り当てます。 今回の例の場合は、192.168.2.1を設定します。 その後、「Add」ボタンから追加を行います。 保存 設定内容を確認し保存を行います。 これで設定は完了です。 動作確認 設定を行ってから約5分後、ユーザAのクライアントは自動的に再接続が行われ、アドレスは192.168.2.1に変更されました。 次にこのユーザAの端末へ、ヘルプデスク用の端末からRDP接続を試してみます。 まず、ヘルプデスク用の端末でCatoクライアントを起動し、Catoクラウドに接続します。 ヘルプデスク用のユーザ(ユーザB)には固定IPを割り当てていないので動的IPの10.41.142.3が割り当てれられました。 このヘルプデスク用の端末からユーザA(192.168.2.1)に対してRDP接続を試してみます。 すると、このように無事接続できました。 ちなみに、この時のログはきちんと残っていました。 まとめ 今回、動的IPにて接続された状態で固定IPを割り当てた場合の挙動が気になり、接続状態で固定IPを設定してみました。 結果としては、自動的に再接続が行われ断時間はほとんどありませんでした。 個人的にはなんとなく、切断してから設定する方が安全なのでは？と思っていましたが、断時間がほとんどないことから切断せずに固定IPを割り当てる方が断時間は短いので、切断する必要は特にないと思いました。 もちろんはじめから固定IPを割り当てることが決まっている場合などは切断されている状態から固定IPを設定するでも全く問題はないと思います。 また、2台同時接続を行った場合は仕様通り、1台目の端末が192.168.2.1を持ち続け2台目の端末には動的IPレンジから10.41.179.103が割り当てられました。つまり固定IPが必要な端末数に合わせてユーザを作成する必要があるということなので、ライセンス数も検討が必要だなと感じました。 最後に固定IPの設定をする際のポイントをまとめて本記事は終わりにします。 動的IPレンジに設定されているアドレスレンジと重複しないように設定をする 動的IPにて接続した状態で固定IPを割り当てた場合、固定IPを使って自動的に再接続され通信断時間はほとんどない 2台同時接続した場合、固定IPが割り当てられるのは最初に接続を行った1台のみで、2台目には動的IPレンジから割り当てられる おわりに 今回、モバイルユーザのアドレス設定についてまとめてみました。 Catoクラウドを導入する際にお役立ていただければ幸いです。

こんにちは。SCSKのふくちーぬです。生成AIが盛んな中、なかなか最新のアップデートについていけていない方は多いのではないでしょうか。私もその中の1人です。。 今更ながらですが、生成AI・Amazon Bedrockに入門してみようと思います。2024年にリリースされたChat with your documentを一緒にみてみましょう。 用語解説 簡単に用語から整理したいと思います。 生成AIとは テキストや画像、音楽等新しいコンテンツを生成できる技術を指します。 ハルシネーションとは 生成AIが事実とは異なる間違った回答をしてしまうことを指します。 生成AIが事実とは異なる回答を自信ありげに提供してしまうことがあるため、私たちユーザーはその回答が真実かどうか判断することが求められています。 この現象は、生成AIが利用している基盤モデルの学習済みのデータには、該当の情報が存在しないため発生してしまいます。 RAGとは RAGは「Retrieval-Augmented Generation」の略で、検索と生成AIを組み合わせた技術です。 質問に関連するドキュメントと質問文を生成AIに読み込ませることで、そのドキュメント情報を元に、応答するコンテンツの作成が可能になります。この手法を使うことで、より正確で信頼性の高い応答が可能となり、ハルシネーションを抑制することに繋がります。 RAGの利用用途として、カスタマーサポートが挙げられます。あらかじめFAQや製品仕様書を読み込ませておくことで、ユーザーに適切な回答を提供することが可能となり、ユーザーヘルプデスク体制の効率化を図ることができます。 AWSでのRAGの選択肢 AWSで実現する選択肢として頻繁に利用されるサービスとして、以下が挙げられます。 どれもデータベースの準備が必要のものとなり、ある程度の技術が要求されます。 Amazon Kendraを利用する Amazon Bedrock Knowledge Basesを使う 2024年4月にリリースされたChat with your documentでは、データベースを作成することなく、RAG の仕組みを簡単に利用できます。 Amazon Bedrock のナレッジベースで個々のドキュメントから簡単に質問できるようになりました aws.amazon.com Amazon Bedrock Knowledge Bases now simplifies asking questions on a single document | Amazon Web Services At AWS re:Invent 2023, we announced the general availability of Amazon Bedrock Knowledge Bases. With Amazon Bedrock Know... aws.amazon.com Chat with your documentを利用した検証 今回はChat with your documentの機能で、簡単にRAGの世界を体験してみます。 モデルアクセスの有効化  サポート対象である、バージニア北部リージョンにて作業を実施します。 Bedrockコンソール上で、「モデルアクセス」ペインを押下します。 Anthropic社の”Claude 3 Sonnet”が利用できるか確認します。 “リクエスト可能”であった場合は、「モデルアクセスをリクエスト」を押下します。 “アクセスが付与されました”であった場合は、本作業は必要ありませんので、次のセクションに移ってください。   “Claude 3 Sonnet”にチェックマークが付いていることを確認します。   「Next」を押下します。   内容を確認して、「Submit」を押下します。 少々時間を置いた後再度「モデルアクセス」ペインを開くと、”Claude 3 Sonnet”に”アクセスが付与されました”が表示されます。 これでClaude 3 Sonnetの基盤モデルが利用できる準備が整いました。 RAGを利用しない一般的なチャットの場合 プレイグラウンド内の「チャット」ペインを開きます。 モデルの選択画面にて、”Claude 3 Sonnet”を選択し、「適用」を押下します。 プロンプト入力画面にて、以下の文章を入力してみます。 AWS Summit Japan 2024は、いつどこで開催されましたか？     AWS Summit 2023については、ハルシネーションが発生していますね。AWS Summit 2023は、2023/4/20,4/21に開催されています。 AWS Summit 2024についても、既に開催済みなはずですが、ハルシネーションとは言わないまでも、想定していた回答が返却されません。 Claude3のモデルは、2023年8月までのデータを学習済みですが、それ以降の出来事は学習されていません。 そのため、上記のような結果になったことが分かります。 https://blog.usize-tech.com/contents/uploads/2024/10/Model_Card_Claude_3.pdf RAGを利用したチャットの場合 オーケストレーション内の「ナレッジベース」ペインを開きます。 モデルの選択画面にて、”Claude 3 Sonnet”を選択し、「適用」を押下します。 Dataの画面にて、下記のAWS Summit資料をアップロードします。 https://blog.usize-tech.com/contents/uploads/2024/10/AWS-Summit-Tokyo-2024-EXPO-Guide.pdf 先程と同様にプロンプト入力画面にて、以下の文章を入力してみます。 AWS Summit Japan 2024は、いつどこで開催されましたか？ AWS Summit Japanは、2024 6/20,6/21に幕張メッセにて開催されましたよね。上記のように正しい回答が返却されることを確認できました。 Chat With your documentの留意点 対象リージョン：バージニア北部、オレゴン、ムンバイ、シドニー、アイルランド、ロンドン、パリ、カナダ、サンパウロ 対象基盤モデル：Claude 3 Sonnet ファイルの種類: PDF、MD、TXT、DOC、DOCX、HTML、CSV、XLS、XLSX。 10 MB 未満のファイル制限があります。 10 MB 未満のテキスト中心のファイルでも、設定された20,000個のトークン制限を超える可能性があります。 ドキュメントやそのデータは基盤モデルには、保存されません。そのため、他のユーザーに利用してもらうためにはきちんとデータベースとして用意してあげる必要があります。 Chat with your document without a knowledge base configured - Amazon Bedrock Learn how to test play an Amazon Bedrock knowledge base without the need to configure a knowledge base. docs.aws.amazon.com によるモデルサポート AWS リージョン - Amazon Bedrock 次の表はFMs、他の リージョンで使用できる と、各リージョンでサポートされているかどうかを示しています。 docs.aws.amazon.com 最後に いかがだったでしょうか。 Amazon Bedrockの Chat with your documentを利用することで、RAGの難しい構成を意識することなく容易に体験することができました。 機会があれば、自分でもデータベースを作成しRAGを利用していこうと思います。 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥