SCSKクラウドソリューション の技術ブログ
全1141件
近年、各種クラウドセキュリティサービスに Remote Browser Isolation (RBI、リモート ブラウザ分離) 機能 が搭載されるようになってきました。 Catoクラウドも、セキュリティオプションとしてRBIを提供しています。 RBIとは何か？どんなメリットがあり、どういった利用方法が考えられるのか？ をご紹介します。 RBI (Remote Browser Isolation) とは？ Webサイトの描画を、端末のブラウザではなくクラウド上の隔離されたブラウザにて行い、結果の画面だけを端末に転送する仕組みです。 例えば、アクセスしたWebサイトにマルウェアが仕込まれていた場合、通常のアクセスだとマルウェアがダウンロードされてしまいますが、RBIを使用している場合、クラウド上で防御され、端末には届きません。 端末の安全を守るのに有効な機能で、Catoクラウドはもちろん、Netskope, Zscaler, Cisco Umbrella といった、各種クラウドセキュリティサービスにも実装されています。 RBIの動作 それでは、CatoクラウドでRBIの動作を見てみましょう。 今回は動作検証用のテストサイトを利用します。このサイトは、アクセスすると自動で無害なテキストファイルがダウンロードされるように設定されています。これがもしマルウェアだったとすると端末に入り込んでしまうという想定です。 以下は、RBI機能は利用せず、通常どおりアクセスした際のスクリーンショットです。 URLを開いただけで、テキストファイルが端末にダウンロード されました。 続いて、CatoクラウドのRBI機能をONにして同じサイトにアクセスします。すると、RBIが動作し、 ファイルのダウンロードは無事ブロックされました。 また、画面上部にRBI動作中であることが表示されています。 このように、RBIはWebサイトの不審な動作を阻止してくれますので、内部ネットワークのセキュリティに大きく貢献します。 では、 すべてのWebサイト表示をRBIに任せれば安心かというと、これは利便性の面で難しい です。 RBIの仕組み上、描画して画面だけ転送するのには数秒かかり、 ユーザとしては表示が遅く感じてしまうため です。 CatoクラウドにおけるRBI運用 では、どういったWebサイトへの通信をRBI経由にすると良いのでしょうか。 信頼できるサイトは通常どおり接続 するのが利便性が良く、 危険性の高いサイトはそもそもアクセスをブロック するべきですので、 危険かどうかの判断が付かないサイト(※)をRBI経由にするのが良い ということになります。 ※URLカテゴリが分類できないサイトや、作成されたばかりで情報のないサイトなど。一般的に、マルウェアサイトやフィッシングサイトといった悪意のあるサイトは、作られては規制されまた新しく作るいうことを繰り返すため、これに該当しやすいです。 Catoクラウドでは、クラウド上の Internet Firewall のAction(Block,Allow,Prompt等)のひとつとして、RBIが指定可能です。条件を指定し、一致した通信をRBIを経由させるよう設定します。 推奨設定は、Webサイトのカテゴリ判定で 「 Uncategorized(未分類) 」および「 Unknown(不明) 」となるサイトをRBI経由にすること です。これは上記の「判断が付かないサイト」に該当するものです。もちろん、この他のカテゴリやURLを指定してRBIを経由させる設定も可能です。 なお、リスク低のアクセスであっても、不審な通信が紛れ込む可能性はあるため、IPSやAnti-Malware等のセキュリティ機能でチェックする必要があります。 注意点 CatoクラウドのRBIには利用上の注意点があります。 1つめは、その名の通りブラウザの通信を対象とした機能のため、ブラウザ以外(メールソフト、クライアントソフト等)の通信には適用されない点です。また、モバイル端末(iPhone、iPad、Android)のブラウザには現状対応していません。 2つめは、RBI経由で表示中のWebサイトにも、文字入力ができる点です。RBI経由であっても、個人情報や機密情報を入力してしまうと、相手先に届いてしまいます。RBI経由ではRead-Onlyにさせるような機能があれば良いのですが。Cato社に要望していきます。 まとめ RBIは、Webブラウザ経由のマルウェア感染等を防ぐ有効な機能です。 IPSやAnti-Malwareといった他のセキュリティ機能と併せて、ぜひ導入をご検討ください。
こんにちは、SCSK三上です。 今回は、気になっていたAmazon QuickSightのPaginated Reportingについて概要と実際に触ってみたので画面イメージなど共有していきます！ Paginated Reportingは簡単にいうと Quicksightで作成したダッシュボードをレポートやスケジュールで配信できる サービスです。 Amazon QuickSight Paginated Reports - Amazon Web Services フルマネージドかつクラウドベースの単一のビジネスインテリジェンス (BI) ソリューションから、レポートとデータのエクスポートを作成、スケジュール、共有します。 aws.amazon.com Amazon QuickSightの特徴についておさらい 今までのBIに関する課題 BIの難しさ 2022年中に生成されたデータ量：98ZB 平均的なBIツール数：4つ 意思決定者によるBiの利用率：<20% BIツールの問題 BIの利用者のニーズやスキルがバラバラ BIツールが多数存在する（Excel、Dashboards、Custom Code Embedding、High-Code Forecasting） Amazon QuickSightとは？ あらゆる分析ニーズに対応する統合BI データリッチな体験を素早く構築 自動スケーリングによる一貫した高性能 従量課金での書かう設定でコストを削減 Amazon QuickSightの利点 あらゆるニーズに対応する統合BI インタラクティブなダッシュボード、Q、組み込み分析、同じソースからのPagintated Reports 全ての場所でインサイト あらゆるアプリやポータル でシームレスなデータ体験を実現するために、広範なAPIを使用して簡単に組み込み可能 拡張された分析 Qによる自然言語での質問、内蔵MLで予測 オートスケーリング SPICEインメモリデータエンジン による1B以上のデータセットまで拡張可能 ポリシーに基づくガバナンス、セキュリティ 行および列レベルのセキュリティ、ロールベースでのアクセス制御 で安全に共有可能 より少ないコストでより多くのものを 従量課金制によるコスト削減 従来のBI環境とQuickSight 従来のBI環境 Amazon QuickSight BI環境のサイロ化 専門トレーニング、各専門スタッフ プラットフォームごとに異なるUI 高価なライセンスとメンテナンスの分離 ハイパースケールでの統合BIサービス 追加トレーニングや技術トレーニングは不要 同じUIで数週間ごとに新機能 コストのかかるライセンスをなくし、従量課金制に Amazon QuickSightの特徴 論理的ネットワーク環境でオンプレなど どこからでもアクセス可能 SPICEを利用して高速にデータアクセス可能 直接データにクエリ発行可能 ML Insightや異常検知やSageMakerとの連携で更なる分析が可能 全ての人にBIを利用 していただくことが可能 例：社内のポータルサイト Paginated Reportingとは？ フルマネージドかつクラウドベースの単一のビジネスインテリジェンス (BI) ソリューションから、 レポートとデータのエクスポートを作成、スケジュール、共有 できるサービス。 クラウドで行うPaginated Reportingについて 高度なフォーマットで印刷可能なレポート 豊富なビジュアルと画像を含む複数ページのPDFレポート PDFおよびCSVエクスポートのスケジュール配信 例：毎週月曜日にエグゼクティブ向けにレポートを送る 統一されたオーサリング ダッシュボードとレポート間での同じデータセットを管理 使い慣れたIFで新たな学習が不要 サーバレスで需要に応じて自動スケール インフラやソフトウェアの管理（ソフトウェアのアップデートを含む）が不要 使用量に応じた従量課金 Paginated Reportingの特徴 その1：複数ページのレポート エクスポート時にテーブル/ピボットテーブルの全ての行をレンダリングする PDFレポートの生成 作成者が定義した 明示的な改ページ により、生成される出力のフローを制御 その2：ヘッダーとフッター ページ番号など、あらかじめ定義されたシステムパラメータを追加可能 ヘッダーやフッターに テキストや画像を追加 して、リッチなビジュアルを作成可能 その3：スケジュール配信 複数ページにまたがる内容の PDF文書をスケジュールする機能 CSVにエクスポートする要約データを選択 その4：スナップショット履歴 レポートのスナップショットにオンデマンドでアクセス Paginated Reportingの料金 タイプ 含まれるユニットレポート 料金 1つのレポート ユニットあたりの追加料金 1ヶ月あたりのプラン 500/月 $500/月 $1.00 年間プラン 4,000/月 $2,000/月 ($24,000/年 $0.50 画面イメージ（レポート作成・スケジュール配信） 今回、既存のダッシュボードをレポート化してヘッダーやフッダーを追加し、スケジュール配信をしてメールでレポートを受け取るところまで実施したので画面をお見せします！ レポート作成 今回はこちらのダッシュボードを利用してレポート化していきたいと思います。 まずはシート名の右にある「+」をクリックし、新規シートで「ページ分割されたレポート」から用紙サイズや向きを選択し追加をクリックします。 追加を押すと、このようにレポート形式のシートが作成されるので、既存のダッシュボードからレポート用のシートに複製してレポートを作成していきます。 （対象ビジュアルを選択>一番右にある「 」を押下>ビジュアルを指定して複製>複製先のシートを選択） ヘッダーやセクションに、テキストやインサイト、計算フィールドなどを駆使するとこのようにレポートを作成することができます！ 今回は、「テキスト」「インサイト」「計算フィールド」を利用して作成しました。 スケジュール配信 作成したレポートを週次の打ち合わせ前にメンバに展開したい時などに便利なスケジュール配信を利用してみます。 対象のレポートから画面右上の共有を選択し、「ダッシュボードの公開」をクリックします。 公開したいシートのみ選択し、ダッシュボードの公開をします。 「スケジュールを追加」をクリックし、スケジュール内容を選択・記載していきます。 ここで対象のシートの選択や、スケジュール設定、Ｅメールの件名や受信者等設定します。 すると、このようにレポートが添付ファイルとしてメール受信できました！ 今回は添付ファイル形式にしましたが、ダウンロードリンクにすることも可能です。 以上画面イメージでした。 感想と今後の期待 今回半年以上ぶりにQuickSightを利用したのですが、かなりアップデートされていて感動しました！！🎵 会議の時に毎回、Excelでピボットテーブル作成してコピーしてパワポに貼りつけて文章考えて…とやることたくさんの方にはうってつけなのではないかと思いました！ レポート中の文章も計算フィールドを駆使して自動化できるのでかなり時間コスト削減されるのではないでしょうか…！ 今後は、ビジュアルの複数選択や配置揃えなどパワポライクになることを期待します…！！ やっぱりQuickSight楽しい～～★と思った時間でした。 以上、ご拝読いただきありがとうございました。 他にもAmazon QuickSight関連の記事を発信していますので、ぜひご覧下さい。 8/4開催！Amazon QuickSight Roadshowイベントレポート オンサイト開催のAmazon QuickSight Roadshowイベントに参加したのでレポートアップします！ やはりオンサイトのイベントは他社の方との交流含めてテンションが上がりますね～ オフィスはもちろん、ドリンクやお菓子のサービス、お弁当まで大変豪華でした！ blog.usize-tech.com 2023.08.15 AWSを用いたデータ活用基盤でデータの可視化・分析・診断を実現しよう！ SCSKでは、アマゾン ウェブ サービス(AWS)を利用した『データ活用基盤の構築から可視化の流れ』や『データを可視化した後の分析方法』 を学べる動画コンテンツを公開しました！ 皆さんのデータ活用にぜひご活用下さい。 blog.usize-tech.com 2023.04.06
どうも、SCSKの齋藤です。 今回はAWS上のサイバー攻撃が起こった際に通知される、「Abuse-report」、「Irregular activity」についてまとめてみました。 この2種類の通知が来た際、それぞれどのような対応をすれば良いのかをまとめていきたいと思います。 また、なぜそのような攻撃が起きるのかの原因も簡単に記載したいと思います。 このブログで記載する原因はあくまで一例であり、悪意のある攻撃者は様々な隙をついて攻撃しますので、このブログで記載する原因以外もあることを念頭においてください。 Abuse-report Abuse-reportとは？ Abuse-reportという通知は、EC2インスタンスを侵害された場合に、AWSから通知されるメールの件名となります。 メールには、なぜAbuse-reportが送付されたかの理由が英文で書かれております。 過去にあったケースですと、DDoS攻撃に加担した挙動や、ポートスキャンを実施したのを確認した場合に送付されることが多いようです。 ちなみに、Abuse-report内に該当のインスタンスIDが記載されています。 受信したらどうしたら良いか？ EC2インスタンスが侵害されているので、速やかにセキュリティグループなどで通信を遮断してください。 その後、原因調査をしてください。主な原因は後述するので、それらが該当するかをまず確認すると良いでしょう。 原因調査後、インスタンスの安全が確認できない場合は、AMIを含めてインスタンスを削除した方が良いです。（バックドアが仕掛けられている可能性があるためです） 原因が判明し、恒久的な対応や再発防止策がなされた場合、AWSへその旨を返信する必要があります。 このAWSへの返信がされないと、AWSアカウントが停止される可能性もありますのでご注意ください。 また、インスタンスを停止するだけでは、恒久的な対応とはならないため、削除をすることを推奨します。削除しなくても良いと判断した場合は、その理由をAWSに報告した方が良いです。 なぜEC2インスタンスの侵害が起こるのか？ 過去事例ですと、セキュリティグループを開けたことが主な原因です。 SSHやRDPの設定で、アクセス元を0.0.0.0にしていると、どこからでも入れてしまうため侵害されやすいです。 アクセス制御は必ず実施しましょう！ Irregular activity Irregular activityとは？ Irregular activityとは、AWSアカウントへの侵害を確認した場合に、AWSから通知されるメールの件名です。 こちらも、なぜ送付されたのか理由が書かれておりますが、件名の通り不審な挙動がAWSアカウントであった場合に通知されます。 例えば、1日で大幅な課金が発生したり、普段使っていないリージョンでの課金が発生したりした場合です。 受信したらどうしたら良いか？ AWSアカウントの侵害なので、ルートユーザーか、IAMユーザーの侵害が考えられます。 しかし、Irregular activityのメールだけですと、それを特定するのが難しいです。 そのため、CloudTrailを確認する必要があります。 CloudTrailのログを見て、意図しない操作を行なっているユーザーが、侵害されたユーザーとなります。 そのユーザーを特定したら、真っ先にコンソールログインの無効化を実施すると良いでしょう。（IAMユーザーの場合） ルートユーザーの場合、パスワード変更などを実施すると良いでしょう。 その後、原因調査をしてください。主な原因は後述するので、それらが該当するかをまず確認すると良いでしょう。 原因調査後、不正に作られたリソースが他にないかCloudTrailをくまなくチェックし、念の為全て削除を実施してください。原因が判明し、恒久的な対応や再発防止策がなされた場合、AWSへその旨を返信する必要がございます。 このAWSへの返信がされないと、AWSアカウントが停止される可能性もありますのでご注意ください。 なぜアカウント侵害が起こるのか？ 主な理由は２つあります。 MFAを有効化していなかったため。 アクセスキーを有効化しており、gitなどに公開してしまったため。 上記理由で、アカウント侵害が起きるケースがとても多いと、私は感じております。 初歩的な対策ですが、絶対に忘れずに実施しましょう！ まとめ 今回はAWSへのサイバー攻撃の際に通知される２つのメールについて概要や対応方法、原因をまとめました。 どれも初歩的な対策で防ぐことができる問題なので、必ず対策を怠らないようにしましょう。 ちなみに、検証環境などで起こることが多いと私は感じております。顧客向け環境などはしっかり対策を練るため、あまり発生しないことが多いです。 たとえ検証環境でも、侵害されれば大きな損害を出しますので、気を抜かずに対策することを強く推奨します。 また、侵害されたことで大量の課金が発生した場合は、恒久的な対策を実施することで、AWS社に利用料減免を交渉することができます。 詳しくは、AWSあるいはアカウント提供元のAWSパートナーへご相談ください。
どうも、子育て支援猫型ロボットの実現を心待ちにしている寺内です。 ついにAmazon Bedrock が2023年9月29日に一般公開されました。 AWS、生成系 AI のイノベーションを加速する新しい強力なサービス / 機能の提供を発表 | AWS aws.amazon.com Amazon Bedrockは、複数の機械学習モデルを共通的なAPIでアクセスできるサービスです。いわば機械学習モデルのエコシステムをAWSは構築しようとしていると考えられます。 さっそくboto3を使って、APIアクセスをしてみましょう。 準備 Amazon BedrockのAPIを使い始める前に以下の準備を行います。 IAMポリシーでの権限設定 APIアクセスに使用するアクセスキーの所有IAMユーザに、以下のポリシーをアタッチします。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "bedrock:*", "Resource": "*" } ] } 機械学習モデルの有効化 AWSマネジメントコンソールでAmazon Bedrockサービスの管理画面を出し、使用したいモデルの有効化を行います。 左のメニューから、”Model access” を選びモデル一覧を出します。 各モデルのEULA(End-User License Agreement:使用許諾契約)を確認します。 右上のEditボタンで、使用したいモデルを選択し有効化します。 以下のように、”Available” から “Access granted” に変われば、利用可能となります。 boto3のバージョンアップ pythonプログラムを実行する環境において、boto3をバージョンアップもしくはインストールします。 Amazon Bedrockのサポートをしているboto3バージョンは、1.28.57 以上となります。 既にboto3がインストール済であれば、以下のコマンドでバージョンアップします。 $ pip install --upgrade boto3 新規にインストールする場合は、以下の手順をご参照ください。 AWS SDK for Python | AWS aws.amazon.com 実行 では早速使ってみましょう。使用するモデルは、以下の2つです。 AI21 Labs の Jurassic-2 Ultra v1 Anthropic の Claude v2 Amazon Titanは、Titan Embeddings Generation 1 (G1) については公開済ですが、Titan Text Generation 1 (G1) は2023年10月1日時点でまだ未公開です。Titan Embeddings Generation 1 (G1) はテキストでの回答はせず、ベクトルデータのみ返すため、LangChainとの連携が必須となりますので、今回は試しませんでした。 ここで紹介するプログラムは、 Amazon Bedrock ドキュメントのサンプルプログラム をベースにして若干の修正をしています。 アクセス権はSTS一時認証のプロファイルを使用 リージョンは、全てのモデルが揃っているバージニア(us-east-1)を使用 Jurassicの実行プログラム import boto3 import json session = boto3.Session(profile_name='sts') bedrock = session.client(service_name='bedrock-runtime', region_name='us-east-1') body = json.dumps({ "prompt": "ブラックホールの構造を教えてください。", "maxTokens": 200, "temperature": 0.5, "topP": 0.5 }) modelId = 'ai21.j2-ultra-v1' accept = 'application/json' contentType = 'application/json' response = bedrock.invoke_model( body=body, modelId=modelId, accept=accept, contentType=contentType ) response_body = json.loads(response.get('body').read()) # text print(response_body.get("completions")[0].get("data").get("text")) Jurassic実行結果 $ python jurassic.py ブラックホールは宇宙にある暗黒の巨大な結晶の中に閉じ込められた場所です。 宇宙には数多くのブラックホールが存在しますが、最も重要なのは、銀河の中心にある「銀河のブラックホール」です。 銀河のブラックホールは、銀河の中心にある巨大な結晶の中に閉じ込められています。 この結晶は銀河の中心にある超重力の場所です。 銀河のブラックホールは、銀河の中心にある超重力の場所で、銀河の中心にある巨大な結晶の中に閉じ込められ Claudeの実行プログラム import boto3 import json session = boto3.Session(profile_name='sts') bedrock = session.client(service_name='bedrock-runtime', region_name='us-east-1') body = json.dumps({ "prompt": "\\n\\nHuman:ブラックホールの構造を教えてください。\\n\\nAssistant:", "max_tokens_to_sample": 300, "temperature": 0.1, "top_p": 0.9, }) modelId = 'anthropic.claude-v2' accept = 'application/json' contentType = 'application/json' response = bedrock.invoke_model( body=body, modelId=modelId, accept=accept, contentType=contentType ) response_body = json.loads(response.get('body').read()) # text print(response_body.get('completion')) Claude実行結果 $ python claude.py ブラックホールの基本的な構造は以下の通りです。 - ブラックホールの中心には重力が非常に強い「奇点」がある。この奇点では、物理法則が破綻する。 - 奇点を取り囲む「事象の地平面」という球状の境界がある。この内側では光さえも脱出できない。事象の地平面の内側がブラックホールそのもの。 - 事象の地平面のすぐ外側には「アククレーションディスク」がある。これはブラックホールに吸い込まれたガスが高速で回転する円盤状の構造。 - さらに外側には強力な磁場と、ブラックホールの両極から噴出する相対論的ジェットがある。 - ブラックホールに落ちていく物質は、スパゲティ化現象に Amazon Bedrockの良いところ さて、上記2つのプログラムを見比べてください。違いは以下3つです。 1. 10行目のプロンプトの文字列。同じ質問をしていますが、その書式が違います。 [Jurassic] "prompt": "ブラックホールの構造を教えてください。", [Claude] "prompt": "\\n\\nHuman:ブラックホールの構造を教えてください。\\n\\nAssistant:", 2. 11行目の推論パラメータです。同じパラメータですが、名称が異なります。 [Jurassic] "maxTokens": 200, [Claude] "max_tokens_to_sample": 300, 3. 30行目の出力文章の取得方法です。 [Jurassic] print(response_body.get("completions")[0].get("data").get("text")) [Claude] print(response_body.get('completion')) それ以外は同じコードになっています。これは、API呼び出し方法が全く同じであることを意味します。 このように、Amazon Bedrockは機械学習モデルへのアクセスを統一します。 モデルに入力する文章構造と出力されるデータ構造が異なるところがあるので、そこはモデルに合わせなければなりませんが、現状のChatGPTやBard毎にAPIや依存ライブラリが異なるよりは開発効率は上がります。 現状ですとLangChainのようなLLMヘルパーライブラリを使うほうが便利な面もまだあると思いますが、今後こうしたモデルの使い分けをワンタッチで行えるようになる利便性の向上に期待したいと思います。
こんにちは、SCSK株式会社の川原です。 Google Cloud が開催するカンファレンスイベント Google Cloud Next が国内4年ぶりに東京での開催が決定！ 米国本社からの講演者を含む多彩な講師陣による基調講演から始まり、先進事例セッション、テーマ別のブレイクアウトセッションなど、 11月15日（水）－16日（木） の二日間にわたり充実のプログラムがご用意されております。今回は 東京ビックサイト での開催です。 この度当社は、Platinumスポンサーとして出展いたします！ IT 業界のみならず様々な業界のリーダー、意思決定者、エンジニア、そして開発者の皆様にご満足頂けるセッションコンテンツが準備されていますので、この機会をぜひご活用ください！ 皆様のご参加を心よりお待ちしております！ ご登録がお済でない方は、まずはこちらからご登録ください↓↓ ※招待コード【 FY23nx_P030 】の入力をお願いします。 Google Cloud Nextとは Google Cloud Nextは、Google Cloudが主催する国際的なカンファレンスイベントです。 毎年、テクノロジー関連のプロフェッショナル、エンジニア、ビジネスリーダーが集まり、クラウドテクノロジーの最新情報を共有します。イベントでは、基調講演、テーマ別のブレイクアウトセッション、ハンズオンセッション、展示ブースなどが用意され、参加者は最新のクラウドテクノロジーに触れる機会を得ます。 この年に一度のカンファレンスは、Google Cloudの最新技術、製品、トレンドについて知識を深め、業界のリーダーや専門家とネットワーキングする素晴らしい機会です。 **参加の価値** Google Cloud Nextへの参加は、以下の点で大きな価値があります。 – 最新のテクノロジートレンドに追いつく機会 – Google Cloudエキスパートとの直接対話 – ネットワーキングとビジネスチャンスの拡大 – クラウド戦略の改善と最適化 最新情報の入手、ネットワーキング、スキル向上の機会を提供し、参加者にクラウドテクノロジーの最前線での存在感を築く手助けをします。 SCSK セッションのご紹介 SCSKのパートナーセッションでは、国内大手製造工場の生産プロセスにGoogle AIを組み込み、業務を変革するまでの過程をご紹介いたします。 開始日時：11/16（木）12:00～12:40 登壇者： SCSK株式会社 ソリューション事業グループ クラウドサービス事業本部 サービス開発推進部 清水 大海 製造業界においてはこれまで以上に競争が激化しており、最新テクノロジーを活用することが生存と成長のカギとなります。AI技術は、競争優位性を築くための強力なツールとなり、未来を切り開く助けになります。 熟練工の技術を AI が超える事は容易ではありません。しかし、日々の業務に AI を組み込み、例えば抜き取り検査が全量検査に、さらに全自動検査になれば生産プロセスに大きな変革を起こすことができます。 本セッションでは、国内大手製造業様における「外観検査業務の改善プロジェクト」を通じ、 高性能なGoogleAIと、それを十分に活用するために 当社がソリューション全体にどのようにAIを組み込み成功させたのかをご紹介します。 SCSKでは長年にわたり製造業のお客様向けのシステム開発を行っており、そのノウハウを活かすことで製造業の現場にAI技術を落とし込むまでの課題を解決することができました。 本セッションを通じ、 製造業DX関係者の方に参考になる内容をお届けできればと思います。 ぜひご登録ください！ SCSKブース SCSKのブースでは、AIはもとより、 ”幅広いGoogle Cloud活用”をご紹介します。 お客様の様々な課題に対し、多様なGoogle Cloud の活用でお応えできることをお伝えいたします。特に推しポイントは、２つです。 エンタープライズでのGoogle Cloud 活用の観点で、SAP on Google や、大規模マイグレーションをご紹介 ERPや業務アプリケーションのプラットフォームとして、また、そこからのデータ活用という観点で、エンタープライズ企業におけるGoogle Cloud活用についてお伝えします。 Google Cloud AI の体験 当社のセッションでもご紹介する国内大手製造業様における、外観検査業務に使えるAIや、コンタクトセンター対応を支援するAIなど、様々な業務知見を持つ当社が、実際のシステム開発プロジェクトでAIをどのように組み込んでいるかお伝えいたします。 ブースでは、実際にカメラでスマホを映しての外観検査や、コンタクトセンターAIなどを体験していただけます！ 他にも、Google Cloud の高度なSIMEサービス、「chronicle」の導入事例や、API管理基盤「Apigee」活用事例など、SCSKはGoogle Cloud活用の総合力で、皆さまの課題解決に貢献します。 ぜひSCSKブースに立ち寄り、ＡＩだけではない、Google Cloudソリューションの広がりに触れてくだいさい！ では皆様、 GoogleCloudNextTokyo’23を楽しみにお待ちください。 当日はSCSKセッションならびに展示ブースへの来場をお待ちしております！
こんにちは、丸山です。 前回に続き、Oracle DBからMySQLへの異種DB移行に関する事例を紹介します。 本日は、③性能の壁です。 【Oracle to MySQL】異種DB移行の壁を乗り越える！①変換の壁、②仕様の壁編 Oracle からMySQLへの変換について実際の事例の中から紹介します。 blog.usize-tech.com 2023.09.28 ③性能の壁 <VIEWのTEMPTABLEアルゴリズム> 同じRDBMSでも、オプティマイザはそれぞれ独自に開発されているので、アルゴリズムも製品によって異なり、その違いにより性能問題が発生してしまうこともあります。その中でも、今回はTEMPTABLEアルゴリズムについて紹介したいと思います。 MySQLのビューに関するアルゴリズムは3種類ありますが、その中でTEMPTABLBEアルゴリズムが採用されるケースは注意が必要です。 では、TEMPTABLEアルゴリズムについて、もう少し詳しく説明します。 以下の例について説明していきます。 ・ イベントの参加者一覧(テーブルt)から、20歳以上の参加者一覧のView(ビューv)を作成 ・ このビューvから東京都からの参加者を抽出したい この場合、VIEWの定義は CREATE VIEW v_Adult (v_No,v_Name, v_Pref ) AS SELECT v_No,Name, Pref FROM Guest WHERE Age > 19; 欲しいデータを取得するためのSELECT分は以下となります。 Select * from v_Adult where v_pref = “東京都”; このVIEWを検索するSELECT分を実行した際に、内部でどのような処理をするのかがアルゴリズムの種類によって変わります。 例えば、MERGEアルゴリズムが採用された場合、 内部ではVIEWの参照先テーブルから直接検索が実施される のに対し、 TEMPTABLEアルゴリズムが採用された場合、 内部でVIEWの実行を実施しその結果を一時保存したうえで本来のSELECT分がその一時保存されたテーブルに対して実行 されます。そのため、必要のないデータが大量に読み込まれ、無駄なI/Oが大量発生した結果、性能が下がってしますのです。 もちろん、上記のSQLはTEMPTABLEアルゴリズムを説明するために用意したものなので、実際はMERGEアルゴリズムが採用され効率的な実行がされますのでご安心を。 実際に起きた一例としては、本来テーブルからは400行ほどの読み込みですむSQL分が、TEMPTABLEアルゴリズムが採用されるケースに該当したため1億行もの読み込みが発生してしまい、処理時間が長くなってしまいました。 そのため、TEMPTABLEアルゴリズムが採用されないように書き換える必要があります。しかし、 書き換えは単純なものではなく、SQLを熟知した技術者がそれぞれのSQLを個別に書き換える必要 がありました。その上、私たちが携わった案件ではVIEWを多用しており、TEMPTABLEアルゴリズムが採用される条件に当てはまりそうなSELECT分が多く、書き換えには多くの時間が発生してしまいます。 そのため、以下のような手順で書き換えを実施し、対応することにしました。 上記のように実施することで、変換工数を抑えつつ、システム全体の性能劣化を防ぎました。 補足 この問題は、OracleからMySQLへ移行した際に必ず起こるというものではありません。 OracleDBで現在記述されているSQLの傾向が今回に当てはまるかどうかを確認してみてくださいね。 では、今回はこれで以上となります。
こんにちは、SCSK浦野です。 やっと暑さが落ち着いてきた気がしますが、よく考えたらあと数日で10月ですね。 さて、9月26日にAmazon DynamoDB データエクスポートで増分のエクスポートが追加され、すべてのリージョンで利用可能との事ですので、早速触ってみることにしました。 Announcing incremental export to S3 for Amazon DynamoDB 前提など 既にテーブルが作成されている状態から開始します。また、エクスポート先のS3についても準備済みとします。 DynamoDBに事前に登録してあるデータは以下です。 増分エクスポートの検証 ポイントインタイム リカバリ (PITR) の有効化 通常のエクスポートでも必要な設定ですので、既に設定している場合はスキップしてください。 [バックアップ]タブを選択、ポイントインタイム リカバリ (PITR)欄から確認できます。 状態が「オフ」となっているときは、編集から有効にしてください。 フルエクスポートの実施 ソーステーブル、送信先S3を選択肢、今まで通りの全体のエクスポートを実行します。 実行結果を見ると、フルで取得されていることが分かります。 S3に保存されたデータを確認してみると、以下の内容になっていました。全部入っていますね。 { "Item": { "Dept": { "S": "Development" }, "Id": { "N": "3" }, "name": { "S": "Charlie Coder" } } } { "Item": { "Dept": { "S": "Sales" }, "Id": { "N": "2" }, "name": { "S": "Bob Salesman" } } } { "Item": { "Dept": { "S": "Administration" }, "Id": { "N": "4" }, "name": { "S": "Diana Admin" } } } { "Item": { "Dept": { "S": "Development" }, "Id": { "N": "1" }, "name": { "S": "Alice Developer" } } } { "Item": { "Dept": { "S": "Sales" }, "Id": { "N": "5" }, "name": { "S": "Eve Consultant" } } } DynamoDBへのアイテムの追加 コマンドを利用して、1件アイテムを追加します。 追加後の結果はこちら。 増分ののエクスポート の実施 S3へのエクスポートのページに移動し、[S3へのエクスポート]ボタンを押して新たなエクスポートを作成、実行します。 エクスポート期間では、先ほど追加のアイテムを追加した時間が入るように期間を設定します。 実行結果を見ると、増分で取得されていることが分かります。 S3に保存されたデータを確認してみると、以下の内容になっていました。該当時間に追加されたデータが入っていました。 ※増分データは、取得時に作成されるフォルダの中ではなく、一つ上の階層に data フォルダが出来てそこに保存されるようです。 { "Metadata": { "WriteTimestampMicros": { "N": "1695885268847648" } }, "Keys": { "Dept": { "S": "Management" }, "Id": { "N": "6" } }, "NewImage": { "Dept": { "S": "Management" }, "Id": { "N": "6" }, "name": { "S": "Frank Manager" } } } まとめ DynamoDB のS3への増分エクスポートを試してみました。 実際の運用で定期的な実行には、Amazon EventBridge などを使用して、スケジュール設定する必要などが出てくるかと思いますが 増分エクスポートができるようになったことで、利便性が向上したと思います。
本記事ではCatoクラウドの管理画面である、Cato Management Application（CMA）を実際の画面を交えて管理画面の見方と主に使用する項目について紹介していきます。 Catoについて知ったばかりでもっと知りたい！や、実際にCatoってどういう操作画面なのか見てみたいという方向けにご紹介させていただきます。 Catoについての詳細に関しましてはこちらの記事をご参照してみてください！ 世界初のSASEプラットフォーム Catoクラウドとは？ Cato Networks社 の Catoクラウド（ケイトクラウド）についてご紹介します。 Catoクラウドは世界初のSASEのサービスであり、強固なセキュリティとシンプルな運用管理を実現します。 blog.usize-tech.com 2023.08.15 管理画面 それではCatoクラウドの管理画面をみていきましょう！ なお管理画面の仕様や配置については、アップデート等で変更する可能性がございますので予めご了承ください。 こちらがCMAの画面となります（2023年9月時点） この管理画面上からネットワーク、セキュリティの設定やネットワークトラフィック、セキュリティイベントに関する分析や確認が可能となります。 各種機能 次に、管理画面から使用できる以下4点の機能についてご紹介していきます。 ナレッジサイト 通知画面 検索機能 日本語訳機能 ナレッジサイト 画面上部右側にクエスチョンマークのアイコンがあります。こちらをクリックすると以下のような項目がでてきます。 「Knowlege Center」の項目を選択すると、Cato社が提供している設定方法やナレッジ情報があるサイトに移動することができます。このサイトは英語表記ですが、翻訳機能を使用すれば日本語での確認ができます。基本的な機能説明や応用方法などの記載があるため何か困った際はご参照いただければと思います。 通知画面 次にベルマークのアイコンです。 通知が確認できる箇所となります。バージョンアップを実施した記録やそれが正常に完了しているか失敗しているか、SocketとSiteを紐づける等の通知が表示される箇所となります。 検索機能 次に以下赤枠の箇所のアカウントメニューについてです。 こちらを選択すると項目を検索できる機能が以下画面のように現れます。 各機能がどこにあったかわからなくなることがあると思いますので、こちらの検索機能を用いて探してみて下さい！ 日本語訳機能 最後にプロフィールのアイコンです。 アイコンをクリックすると以下のような画面が表示されます。Languageの▼のところをクリックすると日本語表記に変換することができます。 ただ日本語訳が上手くされていない箇所が多々あるので日本語表記にする際はご注意下さい！ 設定項目 次に、実際に設定を投入していく画面について説明していきます。 画面上部に記載があるこちらが各種設定の大項目となります。 大項目は、Monitoring、Netowork、Access、Security、Assets、Administration の6つがあります。 各大項目の主な機能内容としては以下となります。 Monitoring ログ確認、利用状況確認等 Network NW全体設定、拠点設定 Access VPN接続設定、端末制御 等 Security FW設定、IPS、アンチマルウェア 等 Assets グループ設定、カテゴリ設定 Administration 管理者登録、通知設定 等 大項目を選択すると画面左側に中項目が出てきます。 中項目を選択すると、それぞれの機能を設定する画面が表示されるので、そこで設定投入していきます。 それでは、大項目の内容についてそれぞれ見ていきましょう。 Monitoring 接続しているユーザーやSite（拠点）の情報・使用状況などの確認ができる項目となります。 Monitoringの画面で確認できる機能の一覧についてみてみましょう（2023年9月時点） Topology 接続されているSite・ユーザーの構成が表示されます。 Events Catoクラウドのすべてのログが一元的に確認できる機能です。詳細について以下ブログに記載しておりますのでご確認ください。 https://blog.usize-tech.com/how-to-filter-catocloud-events/ Sites Overview Site（拠点）一覧やSiteごとのトラフィックがグラフで確認できます。 SDP Users Overview モバイルユーザー（SDPユーザー）の一覧・詳細情報が確認できます。 App Analytics どのアプリが多く使われているかなどアプリケーションに関する分析ができる機能です。 Audit Trail 管理者が行った操作のログを確認できる機能です。 Security Threats 悪意がある、または疑わしいアクティビティを表示できます。 MITRE ATT&CK 自社ネットワークに対してどのような攻撃や攻撃予兆があったのかを確認できる機能です。詳細について以下ブログに記載しておりますのでご確認ください。 https://blog.usize-tech.com/cato-mitre-attck-dashboard/ Cloud Apps Dashboard クラウドアプリの使用状況とリスク分析の確認ができます。 DLP データコントロール ポリシーに基づいて、ネットワーク内のデータおよびコンテンツ関連のアクティビティの確認ができる機能です。 SaaS Security API SaaSアプリへのトラフィック監視および制御を確認できる機能です。 SDP Users SDPユーザーの接続履歴などが確認できます。 Network Dashboard Site-Cato網間のトラフィックが確認できます。 Best Practices Catoクラウドに設定している各機能が、Cato社の推奨設定と一致しているかを確認する機能です。詳細について以下ブログに記載しておりますのでご確認ください。 https://blog.usize-tech.com/catocloud-best-practices/ Stories Dashboard Catoクラウドによって検出されたネットワークに対する潜在的な脅威を確認できます。 Stories Workbench Stories Dashboardで確認できた脅威についての詳細が確認できます。 Reports SiteやSDPユーザー、期間の指定やネットワーク関連やアプリケーション関連などのタイプを選択し関連データと情報をPDFとしてレポートを生成できます。 試しに、MonitoringのEventsがどんな画面か見てみましょう。 上記のようなグラフが表示されます。確認できる内容としては、イベントログの量や確認したいイベントの分類[SecurityやRoutingなど]や日時など指定してログの確認が可能となります。 また、Monitoring項目の中に「Best Practices」という、各設定項目がCato社の推奨としている設定になっているかを確認してくれる機能があります。 ただこちらの機能での設定項目確認については各社利用状況が異なるため、一概には「Best Practices」の機能に従えば良いというものではありません。SCSKでは、各社に適した項目をご提案できる設定診断サービスを提供しておりますので是非ご利用下さい。 Network ネットワーク全体の設定や、Site（拠点）ごとのネットワーク設定を行える項目となります。 Networkはこのような画面となってます。 Networkの項目では以下のような機能が実装されております。（2023年9月時点） Sites 対象のSite名を選択するとそのSiteのイベントログやトラフィックの詳細情報を確認できます。またSocketのLAN側のアドレスやルーティングの設定、LAN Firewallの設定が可能です。 Network Rules QoSやNATなどのネットワークルールの設定を作成できます。 DHCP DHCPの設定が行えます。 DNS Settings DNSの設定が行えます。 Remote Port Forwarding インターネットからのTCP/UDPトラフィックをCatoクラウドを介して指定したリソースに転送を行える機能です。 Bandwidth Management 帯域の管理と優先順位の設定を行えます。 IP Allocation お客様固有の固定グローバルアドレスを取得できます。 Connection SLA SLAの接続に関する設定を行えます。 Floating Ranges BGPを利用する際の機能です。 IP Ranges 複数のポリシーでグローバル IP 範囲を使用する機能です。 Link Health Rules 接続または品質に関連する問題が発生した場合にメール通知をするよう設定が行える機能です。 Last Mile Monitoring 特定のサイトとPoP間のISPリンクの品質を監視できます機能です。 Access VPNの接続設定や端末制御、モバイルユーザー（SDPユーザー）の追加・設定ができる項目となります。 Accessの項目では以下のような機能が実装されております。（2023年9月時点） Users ユーザーの情報確認や作成ができる項目です。 User Groups ユーザーをグループごとに仕分けることができる機能です。 Directory Services CatoアカウントとADドメインを連携するための操作を行う項目となります。 User Awareness Socketの配下、またはオフィスモードのユーザを識別できる機能です。 Single Sign-On Microsoft AzureやOktaなどの Single Sign-On (SSO) プロバイダーを 1 つ選択し、ユーザーおよび管理者に対して、Catoクラウド接続の認証方法を設定できます。 MAC Authentication MAC アドレスの認証制御ができる機能です。 Device Posture Catoクラウドへ接続するデバイスに対して、製品指定や対象の証明書などが入っているかなどで識別し接続を制限する機能です。 Client Connectivity Policy デバイスがセキュリティ要件に準拠している場合にのみ、ネットワークに接続できるようにする機能です。 Client Access ユーザーがCatoクラウドへ接続する際の各種設定を行う項目となります。 Client Rollout Catoクライアントのアップデートを管理する機能です。詳細について以下ブログに記載しておりますのでご確認ください。 https://blog.usize-tech.com/cato-client-rollout/ Always-On Policy CatoクライアントのON/OFFをユーザー側で制御させず、ユーザーからのトラフィックを常にCatoクラウドへ通過させる機能です。詳細について以下ブログに記載しておりますのでご確認ください。 https://blog.usize-tech.com/catocloud-always-on/ IP Allocation Policy SDPユーザーのDynamic IP範囲を定義する機能です。また、特定の SDP ユーザーに対してStatic IPアドレスの割り当ても行える項目となります。 DNS Settings Policy SDPユーザーのDNS設定を管理する項目となります。 Browser Access Catoクライアント証明書を使用して、ブラウザーアクセスポータルに対して認証を行う機能です。 Client Customization SDPユーザーに対して表示させるロゴのカスタマイズができる機能です。 Security インターネットへの通信を制御するInternet Firewallや拠点間の通信を制御するWAN Firewallなどのセキュリティに関する設定を行う項目です。 Firewall機能についての詳細に関しまして以下ブログをご参照ください。 CatoクラウドのFirewall機能について CatoクラウドのFirewall機能について解説いたします。 blog.usize-tech.com 2023.09.28 証明書の確認設定を行う「TLS Inspection」やCASB機能の設定ができる項目となっています。 CASB機能の詳細については以下技術ブログをご参照ください。 CatoクラウドのCASBについて Catoクラウドのセキュリティオプション CASB について解説します。 blog.usize-tech.com 2023.09.12 Catoクラウドで提供しているセキュリティオプションと内容について以下となります。 Next Generation Anti-Malware アンチマルウェア(Anti-Maalware)と次世代型アンチマルウェア（Next Generaation Anti-Malware) IPS Intrusion Prevention System。不正侵入防止システム（DNS Protectionを含む） CASB Cloud Access Security Broker。SaaS・アプリケーション利用の可視化/評価/制御 DLP Data Loss Prevention。機密漏洩や重要データの漏洩対策 RBI Remote Browser Isolation。Webブラウザ分離 SaaS Security API 外部クラウドサービスのAPIによるセキュリティ検査（アンチマルウェア、DLP） Assets ユーザーのグループ設定やカテゴリ設定を行う項目となっております。 詳細については以下Cato Networks社が提供しているKnowlege Baseに詳細が記載されておりますのでご参照ください。 Security check support.catonetworks.com Administration 管理画面を編集できるアカウント（管理者）を追加・設定できる項目となります。 Administrationの項目では以下のような機能が実装されております。（2023年9月時点） Administrators 管理者の一覧が表示されます。管理者の追加もこちらの項目で実施します。 Roles & Permissions 管理者の権限一覧が表示されます。 Login Restrictions ログインの制限の設定を行えます。 Email Notifications メール通知に関する設定を行えます。 Email Customization メールに通知が来るフォーマットの編集を行えます。 Mailing Lists メーリングリストの作成を行えます。 License 契約帯域や契約ユーザー数、契約期間などに関する情報が記載されています。 Sockets Inventory インストールやテナントに接続されたかなどSocketに関するイベントの履歴が確認できます。 API & Integrations APIキーなどにAPI関連の操作を行う機能です。 Log Exporter AuditTrailやSecurityなどログの種類を選択し、Jsonなどのフォーマットでクライアントスクリプトをダウンロードできる機能です。 System Settings システムの設定を行う機能です。メンテナス実施日時の指定など可能です。 まとめ 以上がCatoクラウドの管理画面であるCato Management Application（CMA）となります。 簡単ではありますが各項目の内容と主に使用する項目について紹介させていただきました。 各種機能を管理画面上で設定していきユーザーや拠点、ルールを一元管理・可視化できることが実際の画面を通じて感じていただけたかと思います。 これを機にCatoクラウドに関して更に知りたい事がございましたらお気軽にお問い合わせください。
ソフトウェアやシステムの開発手法の1つにアジャイル開発があります。アジャイル開発はユーザーニーズに素早く対応するための、アプリケーションを高速に開発する手法です。そしてアジャイル開発には、作成したアプリケーションを素早くリリースするためのCI/CD環境が必要になります。 今回は、AWSのCodepiplineを用い、EC2インスタンスへDockerイメージをビルドし自動デプロイする方法を書きます。構成はシンプルなものですが、ご参考になれれば幸いです。 構築環境について 構成図は下記の通りです。AWS上のWEBサイトのCI/CD環境を構築いたします。 基本的な流れ パイプラインの流れは下記の通りです。 Visual Studio code上に作成したファイル群をCodeCommitにプッシュすると、Codepiplineが起動し、2以降が開始 ファイル群の中にあるDockerファイルから、CodebuildでDockerイメージをビルド 作成したDockerイメージがECRにプッシュ ECRにプッシュされたDockerイメージが、EC2インスタンスからプルされる + CodeCommit上にあるWEBサイトのhtmlファイルが、デプロイされる ※すでにECR上に同じDockerイメージがECRにプッシュされている場合は、2と3はスキップ。 利用イメージ WEBサイトの表示内容を変更したい 変更したindex.htmlファイルをCodecommitにプッシュすると、変更したindex.htmlがEC2インスタンスにデプロイされ、WEBサイトの表示内容を変えることができます。 Dockerコンテナを更新したい 変更したDockerファイルをCodecommitにプッシュすると、新しいDockerイメージが作成されECRにプッシュされます。その後EC2インスタンスに新しいDockerイメージがプルされ、新しいDockerコンテナが立ち上がります。 設定方法 前準備 配信先のEC2インスタンスへは、事前に下記の３つが必要になります。 EC2インスタンス用のAWS Identity and Access Management (IAM)ロールをアタッチ CodeDeployエージェントのインストール CodeDeployエージェントの設定ファイルを編集 VPCには下記の3つが必要になります。 VPCエンドポイントの設定 VPCエンドポイントへのセキュリティグループの設定 EC2インスタンス用に作成したIAMロールに対し、プライベートVPC用のポリシーを付与 詳細は、下記をご確認ください。 AWS CodePipeline作成時の確認ポイント – TechHarmony (usize-tech.com) Amazon ECRの説明 Amazon ECR上にリポジトリを作成します。ここではCodebuildでビルドするDockerイメージと同じ名前にする必要があります。ここではリポジトリ名は、img_mywebとしています。 AWS CodeCommitの説明 ローカルの端末にVisual Studio codeをインストールし利用します。Visual Studio code上に作成したフォルダ構成は下記の通りとしました。 [Visual Studio code上のフォルダ構成] ├── buildspec.yml #CodeBuildでビルド実行時に実行するコマンドを記述するYAMLファイル ├── dockerfile #ビルドするDockerイメージの内容を記載 ├── appspec.yml # CodeDeployで利用するでデプロイ処理を記述するYAMLファイル ├── index.html # 配信先のEC2インスタンスへ配布するhtmlファイル └── src │ ├── Docker.sh #EC2インスタンス上で実行させる、ECRからDockerイメージをプルしてコンテナを起動するスクリプト そのあと、CodeCommit上に下記の内容のファイル群をプッシュいたします。Codecommitとローカル端末のVisual Studio codeとの連携には、下記URLが参考になります。 Visual Studio CodeでAWS CodeCommitを使う (zenn.dev) ※ちなみに、AWSのコンソールログイン時にMFAを強制にしていた場合は連携が失敗します。下記方法で回避が可能です。 MFAを強制しながらCodeCommitをgitコマンドや各種ツールから利用する – Qiita 次に、それぞれのファイルについて詳しく見ていきます。 buildspec.yml Codebuildで実行させるbuildspec.ymlを記載いたします。buildspec.ymlとは、CodeBuildでビルド実行時に実行するコマンドを記述するYAMLファイルのことです。ここでは、img_mywebという名前のDockerイメージをビルドします。 version: 0.2 #DOCKER_HUB アカウントを記載 env: parameter-store: DOCKER_USER: /CodeBuild/DOCKERHUB_USER DOCKER_PASSWORD: /CodeBuild/DOCKERHUB_PASS variables: DOCKER_BUILDKIT: “1” phases: pre_build: commands: – echo Logging in to Amazon ECR… #ECRにログインしてDockerイメージをプル – aws ecr get-login-password –region $AWS_DEFAULT_REGION | docker login –username AWS –password-stdin $AWS_ACCOUT.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com #CodebuildのAPI呼び出し制限を回避するため、DOCKER_HUBにログイン – echo Logging in to Docker Hub… – echo ${DOCKER_PASSWORD} | docker login -u ${DOCKER_USER} –password-stdin – docker pull $AWS_ACCOUT.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/img_myweb:latest || true build: commands: – echo docker build… – docker build -t img_myweb . #img_mywebという名前のDockerイメージをビルド post_build: commands: – echo Pushing the Docker image… #作成したDockerイメージ img_mywebをECRにプッシュ – docker tag img_myweb:latest $AWS_ACCOUT.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/img_myweb:latest – docker push $AWS_ACCOUT.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/img_myweb:latest artifacts: files: – ‘**/*’ $AWS_DEFAULT_REGION：使用するリージョンに読み替えてください。 $AWS_ACCOUT：使用するAWSアカウントに読み替えてください。 補足１ pre_buildフェーズにおいて、ECR上の作成済のDockerイメージをプルする、docker pullコマンドを実行しています。この記述を追加することで、ビルドに要する時間をスキップできます。初回やdockerfile変更時などで、ECR上に存在しない場合は、buildフェーズで一からビルドされます。 補足２ Docker Hubのアカウントを事前に用意します。AWS Systems Managerに記載し、それを参照してDocker Hubにログインしています。（buildspec.ymlの 赤文字部分 ）。これを記述しない場合、まれに下記のアラートが発生する可能性があります。これはCodebuildのAPI呼び出し制限に引っかかるためです。 toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit 詳しくは、下記をご確認ください。後述の”AWS Codebuildの説明”においても補足します。 CodeBuildのIPガチャを回避するお話 – ITお絵かき修行 (hatenablog.com) dockerfile 次にdockerfileです。Apacheをプルするだけなのでシンプルなものです。 FROM httpd appspec.yml 次に、Codedeployで実行させるappspec.ymlを記載いたします。appspec.ymlとは、CodeDeployで利用するでデプロイ処理を記述するYAMLファイルです。ここでは、Codecommitにプッシュしたindex.htmlを、配信先のEC2インスタンスの/var/www/htmlディレクトリに配信するように指示しており、その後Docker.shを実行します。 version: 0.0 os: linux files: – source: index.html #配信したいファイル名 destination: /var/www/html #配信先のEC2インスタンスのディレクトリ file_exists_behavior: OVERWRITE #destinationにファイルが既にある場合は上書き hooks: AfterInstall: – location: src/Docker.sh #ECRからDockerイメージをプルし、コンテナを作成するプログラム。詳細は後述 index.html WEBサイトで公開するhtmlファイルです。簡易なものを用意しました。 <!DOCTYPE html> <html> <head> <title>これはテストです。</title> <meta charset=”UTF-8″> </head> <body> <h1>これはWEBサイトです。</h1> </body> </html> Docker.shプログラム img_mywebのイメージをECRからプルし、古いコンテナがある場合は削除＆img_mywebのイメージを用いて、コンテナを起動するプログラムです。ところどころスリープを入れています。appspec.yml上で本プログラムの実行を指示しています。 #!/bin/sh aws ecr get-login-password –region $AWS_DEFAULT_REGION | docker login –username AWS –password-stdin $AWS_ACCOUT.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com sleep 10s sudo docker pull $AWS_ACCOUT.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/img_myweb:latest #Delete old container sudo docker stop myweb sleep 10s sudo docker rm myweb sleep 10s #Create new container sudo docker run -d -p 80:80 –name myweb -v /var/www/html:/usr/local/apache2/htdocs $AWS_ACCOUT.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/img_myweb $AWS_DEFAULT_REGION：使用するリージョンに読み替えてください。 $AWS_ACCOUT：使用するAWSアカウントに読み替えてください。 AWS Codebuildの説明 ビルドプロジェクトの作成 CodeBuildの画面から、ビルドプロジェクトを作成していきます。”ビルドプロジェクトを作成する”ボタンを押します。 ■ソース 作成したCodecommitのリポジトリ名とブランチ名を指定します。 ■環境 ・オペレーティングシステム：Amazon Linux2/ランタイム:Standard/イメージ:Standardの最新を選択します。 ・特権付与にチェックを入れます。Dockerのビルドを可能にするためです。 ・buildspec.ymlに前述した、Docker Hubのアカウントをビルドプロジェクトにて記載いたします。追加設定 > パラメータの作成画面 を押下し下記内容でパラメータを作成ください。 名前 値 タイプ DOCKERHUB_USER DOCKER HUBのIDを指定 パラメータ DOCKERHUB_PASS DOCKER HUBのPasswordを指定 パラメータ ■Buildspec ビルド仕様 は “buildspec ファイルを使用”を選択してください。（デフォルトのままでOKです） その後、”ビルドプロジェクトを作成する”ボタンを押して完了です。 補足 ビルドプロジェクトで利用するロールに、下記のポリシーをアタッチください。ECRにログインできるようにするためです。 AWS管理：AmazonEC2ContainerRegistryPowerUser AWS CodeDeployの説明 アプリケーションの作成 CodeDeployの画面から、”アプリケーションを作成”ボタンを押します。 “コンピューティングプラットフォーム”は”EC2/オンプレミス”を選択します。 デプロイグループの作成 “デプロイグループの作成”ボタンを押します。 ・サービスロール AWS管理ポリシーの”AWSCodeDeployRole”がアタッチされたロールを事前に用意し指定ください。 ・環境設定 ”Amazon EC2 インスタンス”をチェック > タググループ1にて、配布したいEC2インスタンスに付与されているタグ名を記載します。 ・ロードバランサー ここでは無効を指定します。 その後、”デプロイグループの作成”ボタンを押して完了です。 AWS CodePiplineの説明 最後に作成した各Code群をパイプラインでつなぎます。”パイプラインを作成する”ボタンを押下して、作成してきた各構成要素を選択していけば完成です。 結果 最後に、index.htmlファイルをVisual Studio code上で変更して、CodeCommitにプッシュしてみます。 デプロイ前 WEB画面は下記のとおりです。 ※事前にデプロイ先のEC2インスタンスがブラウザから見れるように設定ください。具体的にはEC2インスタンスへのインバウンドのHTTPアクセスを許可してください。 ローカルの端末のVisual Studio code上で、index.htmlの中身を修正します(赤文字：修正行)。 <!DOCTYPE html> <html> <head> <title>これはテストです</title> <meta charset=”UTF-8″> </head> <body> <h1>これは変更後のWEBサイトです</h1> <p>デプロイ成功しました！</p> </body> </html> 同様に、Visual Studio code上でCodecommitへプッシュするコマンドを実行します。 > git add . > git commit -m “modify index.html” > git push origin master デプロイ後： WEB画面は下記のとおりとなりました。変更されていることがわかります。 最後に シンプルな構成でしたが、こちらを理解すると応用ができますので、お役に立てれば幸いです。
こんにちは。SCSK池宮です。 今回は、アクセス解析ツールとして有名なGoogle AnalyticsとBigQueryの連携を試してみます。 2つとも同じGoogleサービスのため相性がよく、実はとても簡単に（数回のクリックで）実現できます。 Google Analytics（GA）でできること まずは、GAって何ができるの？という方向けに、（かなりざっくり）サービスのご紹介です（既にご存知の方は読み飛ばしていただいて大丈夫です）。 Google Analyticsは自分のサイトを訪問してくれた人（達）を分析することができます。 何のページが人気なの？ どんな経路で来た？ どんな操作をした？（ダウンロードやスクロール等） 滞在時間はどのくらい？ etc… これらの情報は「Google Analyticsタグ」をサイトに仕込むことで、簡単に取得できるようになります。 Google Analyticsは基本的に無料で利用することができ、ほとんどの操作がコンソールぽちぽち（GUI）で完結するため、初心者にもハードルが低く設定されています。 もちろん、Google Analyticsコンソールからもアクセス解析データを見ることができますが、BigQueryと連携することで解析データの加工や外部データを組み合わせた幅広い分析を実現できます。 Google AnalyticsとBigQueryの連携 ※今回は既にGoogle Analyticsでデータ収集が完了している状態からスタートします。 ①BigQueryを使えるようにする まずは、連携先のGoogle CloudプロジェクトでBigQueryが有効になっているか確認します。 Google Cloudコンソールから、「APIとサービス」の「ライブラリ」を開く。 「カテゴリ」の「ビッグデータ」から、「BigQuery API」を選択。 「APIが有効です」が表示されていたら準備OK！ ②BigQueryリンクを作成する 続いて、Google AnalyticsとBigQueryを連携するためのリンクを作成していきます。 Google Analyticsコンソールにアクセスして、「管理」画面に入る。 「BigQueryのリンク」から、「リンク」を選択。 連携したいGoogle Cloudプロジェクトを選択。（自分のGoogleアカウントからアクセスできるプロジェクトが表示されます。） データのロケーションやエクスポートタイプ（データを連携する頻度）を選択。 最後に「送信」をクリックすると、リンクが作成！ データを確認してみよう BigQueryにアクセスすると、「analytics_xxxxxxxxx(Google AnalyticsプロジェクトID)」というデータセットが作成されていることが確認できました。 ※1日1回の連携を選択した場合は、1日～2日ほど待って確認してみてください。 実は、Google Analyticsから連携されたデータを見ると一部のデータが入れ子のようになっています。 調べてみるとネスト型と呼ばれるデータ形式だそうですが、このデータをLooker Studioで接続する方法も別記事でご紹介できればと思います。 単体でも十分便利なGoogle Analyticsですが、BigQueryに連携するとデータ分析の幅がぐんと広がるので、是非活用いただけたら幸いです。 最後までお読みいただきありがとうございました。
こんにちは。丸山です。 お久しぶりですが、現在でもオンプレからGoogle Cloudなどのクラウド環境へ移行する際、 OracleからMySQLやPostgreSQLなどのOSSへDB移行を検討したいという問い合わせが多くあります。 以前、異種DB移行について 移行の際の3つの壁 についてお話ししています。 異種DBマイグレーションはこう備える！成功へ導く３ステップとは 異種DBマイグレーションは、事前に移行のハードルを把握し、PoCを通して移行実現性を確認することが大切です。Oracle DBからAlloyDBへの移行など、Google Cloudへ移行する際にDB変更を検討中の方必見です。 blog.usize-tech.com 2022.10.19 そこで今回は、 実際の事例の中からOracle からMySQLへの変換 について紹介します。 以前お話ししました通り、変換には3つの壁があります。 中でも、OracleからMySQLへの移行する際の例は以下の通りです。 その中で、今回は①変換の壁と、②仕様の壁の一例をお話ししたいと思います。 ①変換の壁 <シーケンス> Oracleは機能が充実しているため、OracleではあってもMySQLではない機能があります。その代表的なものがシーケンスです。当社事例では、このシーケンスの変換について 疑似的にシーケンスの機能を作成する変換方針 を取りました。 上手の通り、シーケンスと同じ動きをするファンクションを用意し、1シーケンスごとに1テーブル作成。シーケンス用のテーブルには、MySQLの機能であるAUTO_INCREMENT属性のカラムを用意しています。性能としても問題なく利用できたため採用となりました。 ②仕様の壁 <NULLと空文字の違い> 次に、Oracle とMySQLの違いである空白とNULLの違いについてお話していきましょう。 この違いは、Oracle からPostgreSQLとも同じ現象が起こります。 まず、前提としてOracleとMySQLには、以下の違いがあります。 Oracle DB 空白とNULLを区別せず、自動的にNULLとして処理 MySQL 空白とNULLを区別する そのため、 OracleからMySQLへ移行する際にはOracleでの「空白」を、MySQLでは「空白」として扱うのか、それとも「NULL」として扱うのか、移行方針を決めておく必要があります。 弊社の事例では、空白をNULLをして変換することとしました。 そのため、データ移行の際にデータ移行の際に、 Oracleから出力したCSVデータをMySQLにIMPORTする時に「,,」を「,NULL,」に変換することで対応 しました。 ちなみに、 空白をNULLをして扱うことを決めた場合、SQL文の変換では明確にNULLを指定しなくてはならない ので注意が必要です。 NULLを挿入する場合 insert into <テーブル名> values(…,…,NULL); NULLを検索条件に使用する場合 Where <カラム名> IS NULL (または IS NOT NULL) 今回は以上になります。 次回は、性能の壁の1例をご紹介いたします。
はじめに CatoクラウドのFWaaS（Firewall as a Service）には、3つのFirewallがあります。（2023年9月現在） それぞれの違いは以下の通り、制御対象となるトラフィックです。 対象トラフィック トラフィック例 ① Internet Firewall 内部からInternetへのトラフィック 支店PC→Webサイト モバイルユーザ→Webサイト ② WAN Firewall 拠点間およびユーザ間のトラフィック 本社PC↔支店PC モバイルユーザ↔AWS上の社内システム モバイルユーザ↔支店PC モバイルユーザ↔モバイルユーザ ③ LAN Firewall 拠点内のトラフィック 本社PC↔本社内のシステム 本投稿ではInternet FirewallとWAN Firewallついてさらに詳しく説明していきます。 ※LAN Firewallについては別途投稿予定です。CatoのKnowledgeBaseにも掲載されていますのでこちらもご参照ください！ ソケットLANファイアウォールポリシーの設定 – Cato ナレッジベース (catonetworks.com) 設定方法 Internet Firewall、WAN Firewallともに設定箇所は、[Security]の直下にあります。 Internet Firewall [Security]>[Internet Firewall]を開き、DisabledをEnabledへ変更します。 Internet Firewallにはデフォルトルールが入っており、 Catoが予め明示的に、危ないサイトへの通信をBlock、疑わしいサイトへの通信をPromptしてくれています。 デフォルトで、一番下に暗黙のAllowルールが存在しています。 本投稿ではわかりやすいように明示的に”Any Allow”ルールを追加しました。 [New]よりポリシーに従ってルールを追加していきます。 ルールを追加する際の設定項目は以下の通りです。（2023年9月現在） General ルールの名前やルールの挿入箇所を定義 Source 送信元の定義 Device デバイスの機種を定義 App/Category アプリケーション、カテゴリの定義 Service/Port サービス、ポートの定義 Actions Action Allow , Block , Prompt , RemoteBrowsing(RBI)からアクションを選択 Track イベント出力やメール通知の設定 Time ルールをアクティブにする時間の定義 WAN Firewall [Security]>[WAN Firewall]を開き、DisabledをEnabledへ変更します。 ※Disableの状態では、通信がすべて許可されます。 デフォルトで、一番下に暗黙のBlockルールが存在しています。 本投稿ではわかりやすいように明示的に”Any Block”ルールを追加しました。 [New]よりポリシーに従ってルールを追加していきます。 ルールを追加する際の設定項目は以下の通りです。（2023年9月現在） General ルールの名前やルールの挿入箇所、トラフィックの方向を定義 Source 送信元の定義 Device デバイスの機種を定義 Destination 宛先の定義 App/Category アプリケーション、カテゴリの定義 Service/Port サービス、ポートの定義 Actions Action Allow , Block , Promptからアクションを選択 Track イベント出力やメール通知の設定 Time ルールをアクティブにする時間の定義 補足 補足ですが、以下のような便利な機能もあります。 Section 下図の”New Section”からSectionを作成することで、ルールをグループ化させることができます。 必要項目を設定し、”Apply”するとSecrtionが追加されました。 Exception 該当ルールの右端”…”の”Add Exception”から除外ルールを作成することができます。 必要項目を設定し、”Apply”すると除外ルールが追加されました。 注意点 続いて、ルールを追加する際の注意点についてご説明します。 Firewallのルールを追加する際は、以下4つの点に注意が必要です。 Internet Firewallはブラックリスト型 、WAN Firewallはホワイトリスト型 である点を考慮する リストの順序を考慮する SourceやDestination、App/Categoryは可能な限り制限する（”Any”で設定しない） メール通知頻度を考慮する ブラックリストとホワイトリスト Internet Firewall 前述の通り Internet Firewallは デフォルトで暗黙のAllowルールが存在 しており、必要に応じてBlockルールを追加する ブラック リスト型 です。 一般的なオンプレFirewallはホワイトリスト型のため、Catoクラウドへの移行の際はホワイトリスト型からブラックリスト型へ変換が必要と言えます。 少し面倒な作業に感じられるかもしれませんが、内部からInternetへの通信要件は予測・把握が難しいため、これまでのようなホワイトリスト型でのルールの管理では、将来限界がくる可能性があります。 Catoクラウドへの移行を機に複数ルールのグループ化や、不要なルールの削除等の棚卸作業を実施しましょう！ ブラックリスト型に変換することで、管理がしやすいシンプルな設定になります。 WAN Firewall 一方、 WAN Firewallはデフォルトで暗黙のBlockルールが存在しており 、 必要に応じてAllowルールを追加する ホワイト リスト型 です。 WAN FirewallはこれまでのキャリアのWANではなかった概念のため、Catoクラウドへの移行の際は内部同士の通信要件の洗い出しとルールの設計作業が必要になります。 内部同士の通信要件は、内部からInternetへの通信要件に比べて予測・把握が容易なため、ホワイトリスト型でシンプルに設定・管理が可能です。 順序付きルール CatoのFirewall機能は一般的なオンプレFirewall同様、上位のルールからチェックを行い、一度ルールにヒットした場合そのルール以降はチェックしない仕様になっています。優先すべきトラフィックにおけるルールは上位に設定し、全トラフィックをカバーするルールは下位に設定するといったリストの順序についての考慮が必要です。 ”Any”の利用 設定項目のうち、SourceやDestination、App/Categoryはデフォルトで”Any”つまり”すべて”が選択されていますが、”Any”は非推奨です。 Assets＞GroupsやCustom Apps、Categoriesにてグループオブジェクトを作成する、また設定方法の補足でご説明したExceptionの設定をすることで、SourceやDestination、App/Categoryは必要なもののみに制限することを推奨しています。 メール通知頻度 FirewallのEventsは膨大な量出力されます。 設定項目ActionsのTrackの設定にて、Email Notification(メール通知）にチェックを入れ、 さらにFrequency（通知頻度）で”Immediate”（即時）を選択すると膨大な量の通知メールを受信することになります。 通知メールの量が気になる場合は、”Daily”や”Weekly”を選択することで通知頻度を減らすことができます。 設定例 ここでは、運用上追加および変更が必要となる例を紹介します。 禁止サイトにアクセスできてしまう 稀に、許可されていないVPNソフトを利用したアクセスや、禁止サイトへのアクセスが、デフォルトルール”Default prompt for Categories”にヒットする場合があります。 これは、ユーザの判断で禁止サイトへのアクセスが可能となってしまうことを意味します。 このような場合は、前述の3つの注意点を考慮しながら以下のように個別にルールを作成していきます。 ・ 禁止サイトのURLを指定した個別Blockルールを追加 ・ 許可されていないVPNソフトがカテゴライズされている特定Applicationを指定した個別Blockルール作成 ※対象VPNソフトがどのApp CategoryにカテゴライズされているかはAssets＞App Catalogより確認することができます。 前提として、このような禁止されたアクセスが行われていることを検知するために、Monitoring＞Eventsよりログを定期的にチェックするようにしましょう！ 業務時間外はInternet接続を制限したい 業務時間外はInternet接続を制限させたいという場合にも、Internet Firewallの設定にて実現が可能です。 設定項目のTimeにてCustomを選択すると下図のような設定画面が出力されます。 この設定画面で自由に接続可能時刻をカスタマイズ可能です。 まとめ 今回は、Internet FirewallとWAN Firewallについてまとめました。 セキュリティリスクや、ルールの不整合によるトラブルを軽減するため、Firewallの設定は定期的に見直しを行っていきましょう！ 弊社では、設定診断サービスを提供していますので、設定見直しの際にお気軽にご相談いただければと思います！ なお、弊社の FAQ サイトでは 、よくあるご質問やCato クラウドのアップデート情報を公開しておりますので、是非ご参照ください。 よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp
CatoクラウドのEdgeデバイスである Cato Socket に、新機種 X1600 が追加されました！ Cato Networks社よりお借りした実機を、ハードウェア好きの当社Catoチームが調査・検証しましたので、ご紹介します。 まとめますと、 既存の X1500よりだいぶ大きくなっており、ポート数の多さが特徴的な機種 です。 そもそもCato Socketって？ 拠点をCatoクラウドへ接続するために設置する専用ハードウェアです。PoPへの接続や通信制御を行うオールインワンデバイスで、ゼロタッチで設置できるのが大きな特徴です。 2023年9月現在、以下の機種があります。 機種名 特徴 利用シーン X1500 コンパクトながらCatoクラウドのすべての機能を備えたベーシックモデル。 小～中規模オフィス X1500B X1500の改良型。サイズが少し大きくなり、ハードウェア・ファームウェアが一部変更されている。 小～中規模オフィス X1600 今回ご説明するタイプ。2023年7月リリース。 中～大規模オフィス X1700 主にデータセンタへの設置を想定した大型機。ラックマウント型。 データセンタ等大規模拠点 X1700B X1700の改良型。サイズが少し大きくなり、ハードウェア・ファームウェアが一部変更されている。 データセンタ等大規模拠点 vSocket ハードウェアではなく、パブリッククラウド用の仮想アプライアンス。AWS, Azure, VMware ESXi上で動作する。 パブリッククラウド これがX1600です！ 天板のCatoアイコンが印象的です。フロントのLEDはマルチカラーLEDで、接続中はCato色に点灯します。 外装はプラスチックで角が丸く、金属で四角いX1500よりも優しげな印象です。 背後のケーブルが汚くて恐縮です。当社のリアルな検証環境となっております。 ハードウェアスペック 以下にデータシートが公開されていますので、これに沿って実機を見てみましょう。 X1700, X1600 & X1500 Socket Guides サイズ 幅256mm x 奥行き200mm x 高さ44mm です。 サイズ感を他の機器と比較してみます。上から、X1500, X1600, Cisco891FJ です。 X1500がとても小さいので、比べると大きく感じますね。X1500の倍以上のサイズとなっています。 なお、オプションでラックマウントキットの提供もあります。X1500のラックマウントキットは1ユニットに2台並べてマウントするタイプでしたが、X1600は1ユニットに1台をマウントするタイプとなっています。X1500同様に、電源アダプタも合わせてマウントできます。 また、X1600にはなんと壁掛けキットも用意されています。これは、将来的にWi-Fiモデルの提供予定があるため、アクセスポイントとしてオフィス内に設置する目的のようです。提供予定のモデルについては後述します。 重さ 本体が約1kg、電源アダプタが約200gでした。 なお、X1500の本体は700g程度でしたので、X1600は大きさの割に軽い印象です。 電源 12V電源アダプタが付属します。アダプタのサイズもX1500のものより一回り大きいです。 アダプタは、申込時に利用する地域を申告し、その地域の規格で提供されます。今回は、日本仕様で通常の100V電源・アース付きのプラグです。 本体側の接続部分はロッキングジャックになっており、プラグを差し込んだ後、ネジ式のロックを回して固定します。意図せず抜けることがないので安心です。 消費電力量は、 アイドル時14.3Wh、ピーク時34Wh です。 ファン 裏返すと底面にファンがあります。排熱は左右の側面から出るようになっています。 稼働中は、Socketを持ち上げるとファンの回転音がするのですが、底面を下にして置くと音が小さくなります。X1500と比べるとやはりX1500のほうが静かですが、X1600もオフィスに置いてうるさいということはないです。 スループット性能 X1600のMAXスループットは、上り下り合計で1Gbpsとなります。各Socketを比較すると下記です。 機種 MAXスループット(上り下り合計) (ご参考)Site帯域の目安 X1500/X1500B 500Mbps 300～400M程度まで X1600 1Gbps 600～800M程度まで X1700/X1700B 5Gbps 600M以上 vSocket 仮想マシンのスペックにより可変 – 通常のご利用においては、上り下りが両方ともMAXに出続けるという状況はほぼないため、上記の目安帯域以上でも利用可能な場合が多いです。機種を検討される際は、Catoクラウドの担当エンジニアにご相談ください。 インターフェイス X1600最大の特徴が、豊富なインターフェイスです。 背面の各ポートは以下のようになっています。左から順に解説します。 ポート名 解説 CONSOLE シリアルポートとMicroUSBが用意されていますが、他機種と同様、現在のところユーザは利用することができません。 1(WAN) 1GのCOMBOポートです。RJ45とSFPの口がありますが、どちらか一方しか使用できません。 デフォルトで WAN1インターフェイス となります。WAN以外の用途には利用できません。 2 1GのCOMBOポートです。RJ45とSFPの口がありますが、どちらか一方しか使用できません。 WANにもLANにも利用できます。 3, 4 10GのSFP+ポートです。WANにもLANにも利用できます。 5 2.5GのRJ45ポートです。デフォルトで LAN1インターフェイス となります。LAN以外の用途には利用できません。 6, 7 2.5GのRJ45ポートです。 8 2.5GのRJ45ポートです。デフォルトで Managementポート となります。Socketの初期設定を行う際はこのポートにPCを接続します。 なお、デフォルト状態では1(WAN1)と5(LAN1)のみが有効化されており、その他のポートはDisableとなっています。使用する際は、CMA(Catoの管理画面)からインターフェイス設定を行い有効化する必要があります。 続いて側面です。 側面にはUSB3.0 を2ポート備えています。USB⇔Ethernetの変換アダプタを接続し、Ethernetポートとして利用することが可能です。また、機器の初期化を行う際はここに初期化用のUSBメモリを挿します。 以上インターフェイスの特徴をまとめますと、下記2点がポイントです。 SFP標準搭載、10G回線にも対応 X1700でもネットワークカードの追加によりSFP、SFP+に対応可能でしたが、X1600では標準搭載となっています。 Ethernetポートが最大2.5Gに対応 Cato Socketでは初となる、2.5G NICが搭載されています。対向機器が2.5Gに対応していれば、2.5Gでリンクアップします。Auto Negotiation対応ですので、もちろん従来の1G、100M通信にも問題なく対応します。 なお、 ポートは高性能ですが、Socket本体の処理性能がX1700よりは低いため、前述の スループット性能には注意 が必要です。 (ご参考)複数ポートを利用したLAN構成の例 通常の利用例では、Port5, 6, 7 をLAN側インターフェイスとして利用される場合が多いかと思いますが、X1600に限らず現行のCato Socketの仕様として、 複数のLAN側ポートを同じセグメントに所属させること(Layer2 Portとして利用すること)はできません 。各ポートはLayer 3 Portとなり、独自のセグメントを持つ必要があります。 以下に、LAN側ポートを複数利用する場合の構成例をご紹介します。いずれも当社にて動作検証済みの構成です。 構成例A : ポートごとにセグメントを割り当てる例です。 構成例B : ポートの下で複数のVLANを利用する例です。 なお、いずれの場合も、ポート間・VLAN間の通信は、なんと、 デフォルトではいったんCatoクラウドへ出て戻ってくる大回りな通信となってしまいます 。 Socketで折り返しさせたい場合は、「LAN Firewall」機能にてルーティングとフィルタリングが可能です。LAN Firewallについては近日別の記事にてご紹介予定です。 他機種からの入れ替え方法 Siteで利用中のSocketを、X1500/X1700 から X1600 に入れ替えする場合は、現在のSocketをUnassignし、X1600をAssignし直す必要があります。Unassign後、X1600がAssignされ動作開始するまでの間、Siteは通信断となります。 また、CMA上のNetwork Analytics(Siteのトラフィックグラフ)がリセットされ、交換以前のトラフィックが閲覧不可となるためご注意ください。Eventsはクリアされず保持されます。 また、他機種同様に X1600 2台でのHA(Active/Standby)構成が可能ですが、異なる機種間でHAを構成することはできません。 派生モデルの展開予定 今回検証しているものは X1600 “Baseモデル” と呼ばれる機種ですが、将来的には、以下のような派生モデルの展開が予定されているそうです。 LTEモデル : SIMカードを内蔵し、X1600単体でCatoクラウドへ接続できる機種 Wi-Fiモデル : LAN側に対して、無線LANアクセスポイントを提供する機種 LTE+Wi-Fiモデル : 上記両方の機能を持った機種 今冬リリース予定のようですので、楽しみに待ちたいと思います。 ※上記各モデルはBaseモデルへのモジュール追加ではなく、別機種扱いとして提供される模様です。モデルの変更には筐体交換が必要となる見込みのためご注意ください。正式な情報はリリース時に発表される予定です。 まとめ Cato Socket X1600は、 中～大規模オフィスへの設置を想定した最新機種 です。 X1500よりも高い処理性能と多種のインターフェイス を持ち、様々な利用ニーズに対応します。 現時点では、X1500とX1700の間を埋める中間機的な位置づけですが、派生モデル登場により独自の価値が出てくるものと期待しています。 今後の展開は、情報が入り次第当社サイトでもお知らせしますので、ぜひご確認ください。 よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp
Catoクラウドへの移行を検討されるお客様よりよく聞かれる事の1つに「Cato移行後も、データセンターのDMZにある公開サーバを提供する事ができるか？」というのがあります。答えはYesですがその注意点について記載します。 方法は2つ。Remote Port Forwarding と Local Port Forwarding Catoで内部のサーバを外部に公開するにはPort Forwarding機能を使用します。Port Forwardingという名前からイメージできるかと思いますが、インターネット上に公開するグローバルアドレスとポート番号を内部サーバのプライベートアドレスとポート番号に変換する機能です。これはアプライアンスのFirewall等でもよくある機能で私も利用した経験があります。 Catoの場合はRemote Port Forwarding と Local Port Forwarding の2つの方法がありますので、その違いを構成例を図1に示します。 図1. Remote Port Forwarding と Local Port Forwarding の”イメージ” 2つの大きな違いはCatoを通過するかしないかです。Local Port ForwardingだとCatoを通過しないので、当然Catoのセキュリティチェックは効かず通信ログも記録されません。2つの違いを表1に纏めました。 表1. Remote Port Forwarding と Local Port Forwarding の比較 項目 Remote Port Forwarding Local Port Forwarding グローバルIPアドレス IP Allocationで取得したアドレス ISPから払い出されたSocketのwan1のアドレス セキュリティチェック 可能 不可 通信ログ出力 可能 不可 設定箇所 Network >Remote Port Forwarding Site Configuration > Local Port Configuration 注意点 ・グローバルアドレス個数問題（※1） ・ Port forwardingの通信の優先度（※2） ・中国のPoPは非サポート（※3） ・IPsec Siteでは非サポート ・NAT環境では不可（※4） （※1）IP Allocationで取得したアドレスのうち、例えばOffice365用の固定アドレスを公開サーバ用に使用する事も可能ですが、 アドレスを分けたい場合追加取得が必要になります。4つ以上は有償になります。 （※2） Port forwardingの通信はQoSの優先度で最も低い255が自動的に割り当てられ、且つ変更ができません。 （※3） 中国のPoPに割り当てたIPは設定する事が出来ません。 （※4）上位にルータがあって、Socketのwan1ポートがプライベートアドレスの環境では利用できません。要するにwan1が固定グローバルアドレスの環境でないとLocal Port Forwardingは使えないという事です。尚、PPPの場合はアドレスが変わらなければ出来るかもしれませんが試せてません。 2つの内容を見ると、セキュリティチェック及び通信ログの出力ができる点においてRemote Port forwarding が推奨という事になります。またCatoのナレッジにも「可能な限りRemote Port Forwardingを使う事」という記載があります。 逆にLocal Port Forwardingを使用する例を考えると、公開サーバ設置拠点のトラフィック量が多く、Remote Port forwardingだと優先度が低いせいで公開サーバ宛ての通信が破棄されてしまうケースでしょうか。（上記「表1」の注意点※2です） この場合、Cato契約帯域を増速すればRemote Port Forwardingを選択できる解決策はありますが、勿論コスト増となってしまうので、そこはLocal Port Forwardingのデメリットとのトレードオフになるかと思います。 外部アクセスを許可するリスク 公開サーバを設置するDMZとは、DeMilitarized Zoneの略で「非武装地帯」という意味です。 DMZはインターネットからのアクセスが許可された外部と内部のネットワークの中間にあるセグメントなので、内部ネットワークとの間には当然何らかのセキュリティ対策が施される事が前提とされています。(以前は「DMZの公開サーバが乗っ取られたらそこから社内ネットワークに侵入されるのでFirewallでDMZ→Tru st間はAll Denyにしよう」という話をよく聞いたものでした) したがってCato Socket配下のサーバをインターネットに公開する場合、同じSocket配下にいる社内サーバやクライアントPCとの間にセキュリティを施す必要があります。ではそのセキュリティ対策は何をどこまで行えばよいのでしょうか？ 考えられる事は山ほどありますし完璧な対策を行う事が難しい事はご存じの通りです。また、せっかくCatoを導入する事でこういったところのコストや運用負荷から解放されるはずが、逆戻りとなるのは明らかです。 Catoクラウドはフラットでシンプルなネットワークという志向なので、セグメントの階層化や通信経路が複雑化する設計は避け、例外通信を極力なくす事がより安全で且つ運用負荷を軽減できると思います。 よって社内ネットワークにDMZを残すという考えは捨て「公開サーバはCatoとは別のクラウド（AWSなど）に置く」「公開サーバのセキュリティはAWSサービスを利用する」事とし、万が一公開サーバが攻撃を受けた場合も社内ネットワークには影響がない状態にしておくのが得策かと考えます。 尚、Catoのナレッジには、 本機能を使用する場合は「 外部の送信元アドレスを制限する」ことが強く推奨 されていますが、公開サーバはだいたい不特定多数のアクセスを許可しているので「分かっちゃいるんだけど仕方ないんだよ」という声が聞こえてきそうです。 まとめ Catoクラウドへの移行後も社内ネットワークにある公開サーバを継続利用する事は可能ではありますが、その拠点をCato Socketにした構成でその他サーバやクライアントPCとの境界のセキュリティを考える事が必要となってきます。 尚、2023年前半に「LAN Firewall」機能が追加されていますので、構成によってはこちらを活用できるかもしれません。
Catoクラウドでは、各端末にインストールするクライアントソフトは、利用者にて特に操作を行う必要なく、自動で最新版にアップグレードされます。これにより常に最新の状態が維持され、お客様ネットワークのセキュリティを保つことができます。 しかしながら、端末運用の都合で以下のようなご要望をいただくことがあります。 「運用ポリシー上、ソフトウェアアップデートはすべて端末管理システムから配信したいので、自動アップデートさせたくない」 「最新版で不具合を踏むのが怖いので、テスト端末でテストしてから展開したい」 できます！ Catoクラウドの機能で制御可能です。 以前より機能としては存在しましたが、2023年8月に「 Client Rollout 」として機能強化されていますので、ご紹介します。 Client Rollout とは？ Catoクライアントのアップデート状況を確認したり、OS毎のアップデート方法を設定できる機能です。 Catoクラウドの管理画面(Cato Management Application)の、Access > Client Rollout から確認できます。 Rollout Status の見方 Client Rolloutを開くと、まず「Rollout Status」が表示されます。クライアントの配信情報を確認できるページです。 Windows, macOS, Linux の各クライアントの状況が表示されています。 なお、iOS(iPhone/iPad)に関しては、クライアントのアップグレードはCatoからではなく App Store から行われるため、この画面からは制御できません。 主要な表示項目を説明します。 1) 最新のクライアントバージョン 現在このアカウントに提供されている最新のバージョンです。 Catoクライアントは、最新バージョンのリリース後各アカウントに順次展開されるため、 リリース情報が出た後アカウントに配信されるまで、1～2週間かかる場合があります。 この画面に最新バージョンが反映されると、端末への展開が開始されます。 2) 最新にアップグレード済みのクライアントの割合 直近48時間で 接続のあったクライアントのうち、最新バージョンのクライアントの割合です。 3) 最新バージョンの展開状況 現在の展開状況です。 Available to Pilot Group : パイロットグループ(後述します)にのみ最新版が配信される状態です。 Gradual Rollout : 各端末に順次配信中の状態です。 Available to all Users : すべての端末に最新版が配信される状態です。 最初のスクリーンショットの例ですと、Windows と mac は全クライアントが最新版を利用できる状態で、Linuxは最新版がパイロットグループにのみ配信されています。 何らかの理由でこの配信を止めたいとき(例として、パイロットグループでアップグレード後の不具合が発生し、他端末に配信したくないとき)は、「Pause Rollout」ボタンを押すことで、以下のように展開を停止することができます。 配信を再開する際は「Resume Rollout」を押します。 Upgrade Policyの設定 「Upgrade Policy」タブは、実際のアップデート動作の設定画面です。 OSごとにアップデートの方法を指定できます。 Policy Catoからのアップグレード配信を行うかどうかを設定できます。 Automatic by Cato : Catoからクライアントのアップグレードを配信します。 Managed by Admin : Catoはアップグレードを一切配信しません。 クライアントを最新バージョンにするには、端末管理システムから配布したり、ユーザがインストーラーを使ってインストールする必要があります。 Managed by Adminを選択すると、次の設定項目である「Mode」は選択できなくなります。また、前述の Rollout Status も以下のように表示されなくなります。 Mode クライアントのアップグレード方法を選択できます。 Silent : Catoクラウドへの接続時にバージョンチェックが行われ、新しいバージョンが配信されている場合には、自動でアップグレードが行われます。アップグレード中、ユーザには以下のような通知画面が表示されます。アップグレードには(端末性能やインターネット接続状況にもよりますが)3～4分かかり、この間Catoへの接続は切断されます。 User Managed : 上記と同様ですが、ユーザにアップグレードするかしないかの選択が表示されます。「GET IT LATER」を選んだ場合にも、12時間以上経過後に同じ選択画面が表示されます。「GET IT NOW」を選んだ場合は、Silentと同様にアップグレードが走ります。 なお、このアップグレード動作には、端末の管理者権限は必要ありません。ユーザ権限でアップグレード可能です。 パイロットグループの設定 「Pilot Group」の画面から、先行して最新版を配信するパイロットグループの設定が可能です。対象とするSDPユーザを指定し設定します。 たとえば情報システム部門のメンバのみを入れておき、アップグレード時の動作検証を行うなどの用途に利用します。 最後に Catoクライアントは、バージョン毎に細かな不具合修正や機能追加がありますので、常に最新バージョンにしていただくことをお勧めしております。 お客様の端末管理ポリシーに合わせ、Client Rollout の各機能をご活用ください。 クライアント含め、Catoクラウドの週次アップデート情報を、当社「よくあるご質問」の「リリースノート」にて公開しておりますので、あわせてご参照ください。 よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp
こんにちは。SCSK石原です。 AWSを中心にデータ基盤を作成されている場合、AWS Glueが登場する機会が多いのではないでしょうか。AWS Glueには、ETL機能はもちろん、 システムメタデータ を管理できるAWS Glue Data Catalogがあります。 AWS Glue Data CatalogにはCrawlerという強力な機能があり、自動でスキーマを構成可能です。 また、インフォマティカ（Informatica）では、クラウドデータマネージメントプラットフォームとして「Intelligent Data Management Cloud（IDMC）」があり、その中の一つとして「Cloud Data Governance and Catalog（CDGC）」というデータカタログ機能を含むサービスあります。このサービスは システムメタデータ と ビジネスメタデータ の双方を管理できるものです。 Cloud Data Governance and Data Catalog – 予測データインテリジェンス | Informatica Japan Cloud Data Governance & Data Catalogは、データの探索と理解、信頼性とアクセス性を改善することで、意思決定の向上とアナリティクスの統制を実現します。 www.informatica.com 今回は AWS Glueをより活用するため に、 ETL情報をCDGCで抽出しリネージュを取得、カラムレベルでのデータの流れを把握できる ことを検証します。 全体概要 検証環境の全体概要について、インフラ視点とデータ視点で説明します。 インフラ構成図 インフラ構成は以下の通りです。Amazon EC2にはSecureAgentというランタイム環境をインストールします。EC2からインターネット経由でIDMCに接続します。 VPC外には、データストアとしてAmazon S3、ETL及びデータカタログとしてのAWS Glue、クエリエンジンのAmazon Athenaを利用します。このほかにも、IAMなどのサービスを利用しますが下記図では割愛します。 データ遷移図 コンポーネント間のデータの流れを整理します。AWS GlueにてETLを実行します。ソースシステムとターゲットシステムにはAmazon S3を利用します。 Amazon S3に格納したデータに対してAWS GlueのCrawlerを利用して、AWS Glue Data Catalogにシステムメタデータを登録します。 IDMCからは、Amazon Athena及びAWS Glueの接続コネクタを利用して、スキーマやテーブル情報などのシステムメタデータやカラムレベルのリネージュ情報を取得します。 今回は、Kaggleのチュートリアルで利用するTitanicのデータセットを利用させていただきました。 Titanic - Machine Learning from Disaster | Kaggle Start here! Predict survival on the Titanic and get familiar with ML basics www.kaggle.com AWS側の準備 AWSの設定を行います。 AWS Glue Data Catalogの設定 Amazon S3にTitanicのデータ（CSVファイル）を格納しましたので、AWS Glue Data Catalogに登録します。 AWS Glue Data Catalogのデータベース作成 AWS Glue Classifiersの設定 AWS Glue Crawlerでテーブルを作成 今回の設定値は以下の通りです。 データベース名 ishihara-db テーブル名 titanic AWS GlueによるETLジョブ作成 後ほどリネージュを確認するために、2つのデータソースを結合してAmazon S3にファイルを出力するETLジョブを作成します。 結合に利用したデータは下記のとおりです。 Survived_id Survived_name 0 dead 1 survival ETLジョブ実行後に、出力されたデータに対してAmazon Athenaでクエリできることを確認しておきます。 正常にクエリができていますので、AWS側の設定は完了です。 もし、Amazon Athenaでクエリに失敗した場合は、「age」列を確認してみてください。クローラー実行後はdouble型で定義されていましたが、欠損値があり異なる型が含まれると判断されて、クエリに失敗する事象が発生しました。一つの手段として、欠損値が許容される型（String型など）に手動でスキーマを変更すると実行できるようになります。 フィールド X で「HIVE_BAD_DATA: フィールド X のフィールド値の解析エラー: 入力文字列: "12312845691"」という Athena のエラーを解決します Amazon Athena でデータをクエリすると、次のいずれかのようなエラーが表示されます： 「HIVE_BAD_DATA: フィールド X のフィールド値の解析エラー: 入力文字列: "12312845691"」 「HIVE_BAD_DATA: 列 '0' の解析エラー: ターゲットスケールはソーススケールより大き... repost.aws IAMユーザの準備 Amazon Athenaの接続設定をするためには、AWS IAMのユーザが必要になります。下記のドキュメントに従って適切なポリシーを保持したユーザを作成したのち、アクセスキーを発行します。 POST data docs.informatica.com ドキュメントにアクセスするためにはインフォマティカアカウントにログインが必要です。 IDMC側の準備 次にCDGCからAWSの各種サービスへメタデータスキャン設定を行います。 Amazon Athenaへの接続 接続設定 接続設定は以下の通りです。先ほど作成したアクセスキーを利用します。 検証中に下記のエラーが出力されました。こちらはIAM権限不足によるエラーであり、CloudtrailにAccessDenyのエラーが出力されます。今回の場合では、コンソールアクセス用のIAMユーザで発行したアクセスキーを利用しており、MFAを通さない限りほとんどの操作がDenyされるポリシーが付与されていたことが原因でした。 CON_Athenaのテスト接続に失敗しました。[SDK_APP_COM_20000] error [error [java.sql.SQLException: [Simba][AthenaJDBC](100071) An error has been thrown from the AWS Athena client. You are not authorized to perform: athena:StartQueryExecution on the resource. After your AWS administrator or you have updated your permissions, please try again. [Execution ID not available]]] カタログソース設定（Amazon Athena） Amazon Athenaのカタログソースを構成します。下記のマニュアルを参考に進めます。 POST data docs.informatica.com ドキュメントにアクセスするためにはインフォマティカアカウントにログインが必要です。 事前定義されたカタログソースのうち「Amazon Athena」を選択して、設定します。 先ほど定義した「接続」を使用します。テスト接続が成功することを確認して次に進みます。 まずはメタデータの抽出が有効になっていることを確認して、保存します。 カタログソース設定が完了したのち、実行すると以下のジョブ画面を確認することができます。今回はフィルタ設定をしていないため、今回用に作成したAWS Glue Data Catalog以外のテーブルやスキーマも取り込まれています。 カタログソース設定（AWS Glue） AWS Glueのカタログソースを構成します。下記のマニュアルを参考に進めます。 POST data docs.informatica.com ドキュメントにアクセスするためにはインフォマティカアカウントにログインが必要です。 2023年9月現在、AWS Glueのコネクタはプレビュー版です。 カタログソース設定をしたのち、実行した結果は下記のとおりです。 カタログソース設定（Amazon S3） Amazon S3のカタログソースを構成します。下記のマニュアルを参考に進めます。 POST data docs.informatica.com ドキュメントにアクセスするためにはインフォマティカアカウントにログインが必要です。 カタログソース設定をしたのち、実行した結果は下記のとおりです。 接続の割り当て Amazon Athena,AWS Glue,Amazon S3のメタデータ抽出が完了したのち、関連する情報のマッピングを行います。 Amazon Athena（S3__ishihara-techharmony-01-bucket）はAWS Glue Data Catalogを参照しており、実データはAmazon S3に存在するため、Amazon AthenaのカタログソースとAmazon S3のカタログソースをマッピングします。 AWS Glue（S3__ishihara-techharmony-01-bucket）はAWS Glue Data Catalogを参照しており、実データはAmazon S3に存在するため、AWS GlueのカタログソースとAmazon S3のカタログソースをマッピングします。 AWS Glue（ATHENA-H_ATHENA-DB）はAWS Glue Data Catalogを参照しているため、Amazon Athenaのカタログソースとマッピングします。 AWS Glue Data CatalogはAmazon Athenaのカタログソースとして登録されているように見受けられます。 オブジェクトの一致率が100%になっていない箇所があります。Amazon S3のカタログソース設定で、不要なファイルをスキャンしていることが原因です。また、Amazon Athenaの場合は当方で作成していないリソース（AWS Glue Data Catalog）の情報もスキャンされているためです。 結果 AWS GlueをCDGCでスキャンすることで、 カラムレベルでデータの流れを確認することができるようになりました 。データの流れを可視化できることにより、データの透明性を高めることができます。 大規模なデータ基盤となれば、データリネージュが必要になると考えております。この記事が役に立てば幸いです。
Catoクラウドのダッシュボード機能のひとつ、 MITRE ATT&CK ダッシュボード をご存じでしょうか。 お客様ネットワークのセキュリティ対策にぜひご活用ください。 そもそもMITRE ATT&CKとは? MITRE ATT&CKとは、米国の非営利団体であるMITRE(※)が公開している、 サイバー攻撃の戦術や手法に関するフレームワーク です。 ※脆弱性情報の識別番号であるCVEを管理運営している組織です。 2013年に考案された後、4半期に一度以上アップデートされ、現在まで常に最新の脅威情報や防御策などが追加され続けています。 MITRE ATT&CKは、以下のWebサイトにて公開されています。 MITRE ATT&CK® attack.mitre.org 一番上の列(Reconnaissance, Resource Development, Initial Access…)が攻撃の Tactics(戦術) で、表の左から右に向かって進行します。 各戦術を簡単に解説します。 Tactics 意味 概要 Reconnaissance 偵察 攻撃者が攻撃を計画するための情報を収集しようとしている Resource Development リソース開発 攻撃者が攻撃に必要なツールや環境を作成しようとしている Initial Access 初期アクセス 攻撃者が標的へのアクセスを試みている Execution 実行 攻撃者が悪意のあるコードを実行しようとしている Persistence 永続化 攻撃者が不正アクセスし続ける環境を確保しようとしている Privilege Escalation 権限昇格 攻撃者がより高いレベルの権限を取得しようとしている Defense Evasion 防衛回避 攻撃者が検知されないようにしている Credential Access 認証情報アクセス 攻撃者がアカウントやパスワードを盗もうとしている Discovery 探索 攻撃者がアクセス先の環境を調査している Lateral Movement 水平展開 攻撃者が環境内の他の標的へ移動しようとしている Collection 収集 攻撃者がデータを収集しようとしている Command and Control C&C 攻撃者がCommand&Controlサーバとのアクセスを確立しようとしている Exfiltration 持ち出し 攻撃者がデータを持ち出そうとしている Impact 影響 攻撃者がシステムを操作、中断、または破壊しようとしている 各戦術の下にあるのが、 Techniques(技術) です。その戦術を行うために使われる「やり方」です。 たとえば、Reconnaissanceの下にある “Active Scanning” は、対象システムに対するポートスキャンなどを指します。 また、各Tactics(戦術)は TAxxxx、各Techniques(技術)は Txxxx という固有の識別番号が付与されています。 MITRE ATT&CK は、これに沿って各Techniquesへの対策を考えたり、サイバー攻撃の訓練シナリオを計画したり、また実際に不審なアクセスを検知した際に、攻撃の段階や目的を特定して対処を行うために利用されます。 CatoクラウドのMITRE ATT&CK ダッシュボードとは CatoクラウドのMITRE ATT&CK ダッシュボードは、お客様のCatoクラウド内の通信について、IPSの検知状況をMITRE ATT&CKのフレームワークに沿って整理したものです。 このダッシュボードを見ることで、指定の期間内に自社ネットワークに対してどのような攻撃や攻撃予兆があったのかを知ることができます。 MITRE ATT&CK ダッシュボードは、Cato Management Application の Monitoring > MITRE ATT&CK から表示できます。他のダッシュボード等と同様に、表示期間の指定が可能です。 上記の例ですと、Tactics「Collection(攻撃者がデータを収集しようとしている)」に該当する通信が、360件検知されています。 その内訳を見ますと、Techniques「Data from Local System(ローカルシステムからのデータ収集)」に該当する通信が、4つの端末から、360件発生している、となっています。 なお、TacticsのTAxxxx や TechniquesのTxxxx の識別番号は、MITRE ATT&CKで定義されているものと同一です。 「Data from Local System」の箇所をクリックすることで、さらに詳細が表示されます。当該Tactics・Techniqueの詳細や、発生件数のグラフ、通信元IPアドレス、OS等です。 また、SourcesのIPアドレスをクリックすると、その端末について検知したIPSのEventsが表示されます。ダッシュボードからすぐログ調査に移ることができるため便利です。 この例では、Eventsを見ると、Catoクラウドの拠点内の端末から海外の不審なドメインのWebサイトに対しPOST通信が行われ、IPSでBlockされていました。この動作が、Tactics「Collection(攻撃者がデータを収集しようとしている)」の、Techniques「Data from Local System(ローカルシステムからのデータ収集)」と判定されています。納得です。 上記は検証環境のものですが、実際にお客様環境でMITRE ATT&CK ダッシュボードを確認すると、意外に検知件数が多く、驚かれたかもしれません。 このダッシュボードはCatoクラウドのIPS機能での検知を表したものですが、IPSでBlockした通信だけでなく、Monitorしただけの通信も含まれているため、攻撃でない通信を過検知し表示している場合があります。 ダッシュボードの右上にて、「Monitor & Block」「Block」「Monitor」と検知種別を絞ることができますので、「Block」のみにしてみると、実際にCatoクラウドが通信をBlockした、危険度の高い内容のみを確認することができます。 検知にどう対処したらよいか MITRE ATT&CK ダッシュボードで検知があった際は、通常のIPSでのインシデント検知と同様に、お客様のセキュリティポリシーに沿ってご対処ください。 一般的には、以下のような対応が多いかと存じます。 対象の通信元の IPS等セキュリティログを確認し、問題のある通信かどうかを調査する。 意図しない通信である、不審な通信である場合には、その通信元端末をネットワークから遮断し、ウィルスチェック等の調査を行う。 不審な通信であった場合には、MITRE ATT&CK に沿って、どの Tactics のどの Techniques が行われたのかを確認し、影響を調査する。 MITRE ATT&CK をもとに、再発を防止する対処を検討する。 また、このダッシュボードを活用し、以下のような運用を継続して行うことで、攻撃に繋がる可能性のある通信を防ぎ、ご利用環境のセキュリティを強化していくことが可能です。 MITRE ATT&CK ダッシュボードにて、Monitor として検知されている内容を確認する。 Tactics と Techniques ごとに、Eventsログで通信の詳細を確認し、不審な通信が無いかを調査する。 不審な通信があった場合は、Internet Firewall などで Block するルールを追加する。 最後に MITRE ATT&CK ダッシュボードの詳細については、下記の Catoクラウドナレッジベースも合わせてご参照ください。 Working with the MITRE ATT&CK® Dashboard 日本国内では知名度が低めの MITRE ATT&CK ですが、米国企業においてはすでにこのフレームワークを用いたセキュリティ対策が広く取り入れられています。 お客様のネットワークをよりセキュアに運用するため、Catoクラウドの MITRE ATT&CK ダッシュボードをぜひご活用ください。
どうも、Catoクラウドを担当している佐々木です。 今回は、CatoクラウドのQoSについて設定方法と仕様を紹介します。 ※画⾯は2023年9⽉時点のものです。機能アップデート等で変わる場合がありますので、あらかじめご了承ください。 CatoクラウドのQoSについて CatoクラウドにもQoS機能があります。一般的なネットワーク機器と同じように帯域制御も優先制御も実施可能です。 Catoクラウドユーザーでは、以下の用途でよくQoSを利用されています。 Catoクラウドの契約帯域を圧迫しないようWindows Update通信で利用できる帯域を限定する 音声（IP電話）やWEB会議の通信を優先する QoSはSocket、Catoクラウド内の両方で動作しております。 Socket配下のユーザーからの通信の場合、原則SocketでQoSに関する制御を実施します。 SDPユーザーの場合、Catoクラウド内で設定したQoSに基づいた制御は行われますが、 Catoクラウド内だけで動作するため実質意味がありません。 ※SDPユーザーではQoSはかからない、と思っていただいてOKです。 また、CatoクラウドのQoSは、 デフォルト設定だと契約帯域の1.2倍以上の通信が発生した時のみ優先制御と帯域制御を行います。 つまり 「Cato経由のトラフィックに余裕がある時は、特に通信制限されない」 ということです。 ※設定で常時動作させることも可能です。 ※細かい仕様は、複雑な話になりますので、文末の 「CatoクラウドQoSの仕様」 に記載します。 CatoクラウドのQoS設定方法 設定方法の前に、CatoクラウドのQoSの重要概念であるプライオリティについて説明します。 プライオリティについて CatoクラウドのQoSでは、各ネットワーク・フローに「P値（プライオリティ）」という パラメーターをタグ付けします。 「P値」を利用してQoSの優先制御を実施しており、「P値」が低いほど優先度高く処理されます。 「P値」は2～255の値を設定でできます。 ※0 と 1 は Cato 管理トラフィック用に予約されています。 プライオリティのデフォルト値 「P値」はデフォルトで以下の通り設定されています。 要件に応じて変更可能ですが、 デフォルト値はそのまま利用し、必要に応じてルールを追加しているユーザーが多いです。 P10：WANまたはインターネット経由の音声トラフィック P20：WANまたはインターネット経由のリモート デスクトップ (RDP) P30：WANまたはインターネット経由のファイル共有 (SMB) P40：上記以外のWANトラフィック P255：デフォルト – 上記外のインターネットトラフィック 設定方法 QoSを利用するためには、以下2つを設定する必要があります。 Bandwidth Management ：P値やP値毎に利用可能な帯域幅を割り当てるための設定です。 Network Rules ：上記で設定したP値をどのようなトラフィックに割り当てるかの設定です。 Bandwidth Managementの設定方法 Bandwidth Managementは、アカウント全体に共通のルールを設定する方法とサイト単位で設定する方法があります。 ▼アカウント全体に共通のルールを設定する方法 CMAにログインし、 「Network」 ＞ 「Bandwidth Management」 を選択します。 新しいプライオリティルールを追加する場合は、右端の 「New」 をクリックすると、設定ウィンドウが表示されます。 ※既存のルールを設定する場合は、該当のルールをクリックください。 Priority ：任意のP 値を入力（2～254まで） 各プライオリティで利用可能な帯域幅について「制限するか」「制限しないか」を設定します。 プルダウンから以下が選択できます。 No limit ：帯域幅を制限しません。つまり、混雑時に該当プライオリティの通信帯域幅を無制限に確保するということです。 Always limit ：常に帯域幅を制限します。 QoSを常時稼働させる場合、この設定にする必要があります。 Limit only when line is congested ：混雑時のみ帯域幅を制限します。 混雑時＝Cato契約帯域の1.2倍のトラフィックが発生した時になります 優先度の高いルールを「No limit」で設定すると、混雑時に下位のルールで帯域が確保されなくなります アップロード/ダウンロード時にそれぞれ確保する帯域幅を設定します。 帯域幅は、Catoへの接続ライセンスに対する割合（％）か、スループット（Mbps）で設定できます。 この項目は帯域幅制限の有無を「Always limit」「Limit only when line is congested」にした時だけ設定可能です アカウント全体に設定する場合、％で設定することを推奨します（サイトによって契約帯域が異なるため） ▼サイト単位で設定する方法 サイト単位で設定する場合、アカウント全体に設定したポリシーを上書きする（Override）といった動作になります。 そのため、アカウント全体の設定ポリシーにない新規ルールを追加すること、もしくは削除することはできません。 拠点単位で適用ルールを変えたい場合は 「Network Rules」 で制御可能です（詳細はNetwork Rule設定方法に記載） CMAにログインし、 「Network」 ＞ 「Sites」 から設定したいサイトを選択します。 「Site Configuration」 ＞ 「Bandwidth Management」 を選択します。 あとは、設定を上書きしたいポリシーを選択し、 「Override」 をEnableにしてから設定を変更ください。 Bandwidth Managementの設定イメージ 上記設定の場合、以下のように動作します（Catoの契約帯域を100Mbpsとして考えます）。 P10 ：常時、契約帯域幅の50％（＝50Mbps）を確保します。 50Mbps以上の通信が発生した場合、パケットは破棄されます。 ※すべてのCatoトラフィックが契約帯域以下でも、P10として50Mbps以上の通信が発生するとパケットは破棄されます。 P20/P30 ：混雑時のみ契約帯域幅の15％（15Mbps）を確保します。 混雑時に15Mbps以上の通信が発生した場合、パケットは破棄されます。 ※すべてのCato経トラフィックが契約帯域以下の場合、15Mbps以上の通信が発生してもパケットは破棄されません。 P40 ：常時、利用可能な帯域を確保しません。 混雑時は、P10～30で利用していない帯域分の通信が可能です。 Network Rulesの設定方法 Bandwidth Managementで作成したプライオリティをどのようなトラフィックに定義するのか設定します。 CMAにログインし、 「Network」 ＞ 「Network Rules」 から右端の 「New」 をクリックします。 ※既存のルールに適用する場合は、該当のルールを選択ください。 「Source」や「App/Category」などプライオリティを適用したい通信要件を設定いただいたうえで、 「Configuration」 の 「Bandwidth Management」 で任意のプライオリティを定義ください。 Network Rulesの設定イメージ 送信元IP 192.168.1.0/24のVoip通信はプライオリティをP10にする、という設定になります。 「Source」をサイトで設定すれば、特定のサイトの特定の通信のみプライオリティを定義することも可能です。 QoSに関する設定は以上です。 QoSの確認方法 「Priority Analyzer」 でQoSの動作状況を確認できます。 まず、CMAにログインし、 「Network」 ＞ 「Sites」 から設定したいサイトを選択します。 「Site Monitoring」 ＞ 「Priority Analyzer」 を選択すると、以下のようにステータスが表示されます。 各プライオリティの「＋」マークをクリックすると以下のように詳細な情報を確認できます。 なお、以下のように「Usage & Health」のバーが黄色、もしくは赤色の時は注意が必要です。 黄色 ：通信状況に問題が発生していることを示しています（輻輳などが原因でパケット送信に遅延が出ているなど） 赤色 ：帯域がひっ迫し、パケットを破棄している状態 黄色や、赤色が多くみられる場合は、QoS設定の見直しをご検討ください。 Windows Update通信を制限する設定 毎月のWindows UpdateがCatoの帯域を使い切ってしまって困っている、、、 というお問い合わせをよくいただきます。 CatoのQoSで、Windows Updateに関する通信を制限する設定サンプルを共有します。 ※実環境での設定は、お客様通信要件や「Priority Analyzer」などで状況確認したうえで、ご検討ください。 設定イメージ ▼Bandwidth Management ▼Network Rules Bandwidth ManagementでP254の通信帯域は常に10％に制限する、というプライオリティを定義しました。 そのうえで、Windows Updateの通信がP254となるようNetwork Ruleを設定しています。 この場合、Windows Updateに関する通信は常時帯域の10％までになるので、 業務中にWindows Updateの通信が原因で輻輳が発生するという問題は少なくなると思います。 この設定でも輻輳が発生する場合は、Windows Update関係なく、業務トラフィックが想定以上に発生していることになりますので、 Catoの利用帯域そのものを見直したほうがよいかもしれないですね。 CatoクラウドのQoS仕様 CatoクラウドのQoSでは、 契約帯域の1.2倍 以上の通信が発生した時のみ優先制御と帯域制御を行います。 詳しく説明します。 まず、CatoクラウドではLeaky Bucketアルゴリズム ※1 を利用して、帯域幅とバースト性の限界を測定しています。 ※1：Leaky Bucketとは・・・ シェーピングなどで利用するアルゴリズムのことです。 底に穴の開いたバケツに水を注ぐと常に一定量漏れ出すという概念のアルゴリズムで、 ネットワークに置き換えると、バケツの底の穴からパケットが一定の速度で流れ出すモデルになります。 つまり、Catoクラウドでは、バケツが満杯になるかを常に監視しています。 このバケツは容量が決まっており、Catoの契約帯域x1.2倍になります。 ※例えば、Catoの契約帯域が100Mbpsの場合、120Mbpsがバケツの容量です。 通常のフロー バケツが満杯にならない限り、QoSのプライオリティに関わらず、パケットは届いた順に送信されます。 バケツが満杯になると、パケットはキューに格納され、キューの優先度（P値）に従い順番に送付されます。 キューが満杯になると、パケットは破棄されます。 キューのサイズは「Bandwidth Management」で定義した帯域幅になります。 帯域幅を定義していない場合、「契約帯域幅 – 優先度の高い他のキューの合計」がキューのサイズになります。 例外 ただし、上記には例外があります。 「Bandwidth Management」で 「Always limit」 を設定した場合、バケツが満杯にならなくてもキューに格納され、 キューが満杯になるとパケットが破棄されてしまいます。 まとめ QoSは難しく考えられがちですが、設定はシンプルです。 帯域を有効活用するためには必須な機能になりますので、お困りの方はぜひ導入をご検討ください。 「QoS」について弊社の 「Catoに関するFAQサイト」 にも多数情報ございますのでご参考にください。 よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp 最後に、SCSKではPoCから導入、運用まで幅広くCatoに関する支援を行っております。 本番構成への移行を見据えたPoC構成や、PoCでつまづきやすい点のサポートなど、豊富な導入実績を基にご支援いたします。 ぜひお声がけください！
Catoクラウドの「 CASB 」について解説します。 CASBは、Catoクラウドでは標準搭載機能ではなくセキュリティオプションとなります。サービス体系については以下を参照ください。 Catoクラウドのサービス体系について Catoクラウドのサービス料金を含むサービス体系、オプションやマネージドサービスについて紹介します。 blog.usize-tech.com 2023.08.17 CASBとは CASBとは、 Cloud Access Security Broker の略称で、SaaSやクラウド・アプリケーションと利用者（エンドユーザー）の間に位置するのがCASBとなります。クラウドベースのアプリケーションとのやりとりをすべてモニタリング（監視）し、企業のセキュリティ・ポリシーを適用します。 いまや、すべての企業において、SaaSやクラウドアプリケーションの採用が急激に拡大する中、CASBは企業のセキュリティ・ポリシーに必要不可欠な機能となっています。 CASBが無い場合は、IT部門やセキュリティ部門の許可なく、従業員によって利用されているアプリケーション、 シャドーIT が数多く存在します。シャドーITとは、企業のIT部門やセキュリティ部門が把握または認知していない、従業員によるIT利用を意味します。 IT部門やセキュリティ部門が許可していない（場合によっては認知ができていない）アプリケーションは、当然のことながらアクセス制御は行えず、脅威やリスクから適切な保護を行うことができません。また、企業の機密情報や知的財産のやり取りが含まれている可能性もあります。さらに、未認可（未承認）のアプリケーションには、脆弱性があり、サイバー攻撃の標的になる可能性や、情報漏えいのリスクも考えられます。 このような脅威やリスクに対処するためのソリューションがCASBとなります。 CASBは、このようなシャドーITの可視化から、未承認（未認可）のアプリケーションだけではなく、承認済（認可済）のアプリケーションについてのアクセスもより詳細に制御し、許可されたユーザのみが、許可された認証情報を用いてアクセスを行えるようにするものです。 CASBは、以下の4つの基本機能があります。 可視化（Visibility） アセスメント（Assessment） 強制（Enforcement） 防御（Protection） それでは、それぞれの機能について解説を行います。 可視化（Visibility） シャドーITに対処する最初のステップとなり、SaaSやクラウドアプリケーションの使用状況を可視化します。 Catoクラウドでの可視化は、SaaSやクラウドアプリケーションの使用状況を表示する “ Cloud Appsダッシュボード “を提供します。 Cato Management Application（以下、CMA） [Monitoring]>[Cloud Apps] 特に何も新たな設定を行う必要はなく、CASBのセキュリティオプション契約を行うことで、ダッシュボードが表示され、すぐに利用することができます。 ・発見されたアプリケーション、リスクの高いアプリケーション ・利用ユーザ数、利用トラフィック量 ・Topアプリケーション（認可/未認可別、リスクスコア別）、Topカテゴリ ・アプリケーションリスク比率、認可/未認可アプリケーション比率・ユーザ比率 ・地理ロケーション情報（アプリケーションの本社所在地） アセスメント（Assessment） 次のステップは、特定アプリケーションを分析し、脅威やリスクを適切にアセスメント（評価・分析）することです。 CatoクラウドのCASBアセスメントでは、独自の Application Credibility Engine（ACE） を利用しています。 ACEは、データ収集を自動化し、各アプリケーションのプロファイルを迅速・正確に評価し、リスクスコアを提供します。 リスクスコアは、全10段階で 1-3：Low 、 4-6：Medium 、 7-10：High となります。 CatoクラウドのACEは、 クラウドアプリケーションカタログ（App Catalog） で確認することができます。また、アプリケーション毎に、Sanction（認可）を行うことも可能です。 CMA [Assets]>[App Catalog] ・評価されたアプリケーション：タイプ別、カテゴリ別、リスクスコア別、ステータス別、本社所在地別 ・アプリケーション毎情報：コンプライアンス（ISO、PCI-DSS、SOC等）、セキュリティ（SSO、MFA等） CatoクラウドのCASBは、2022年2月にリリースされています。ACEに登録されているクラウドアプリケーションカタログ（App Catalog）の数が、CASBを選ぶ上での重要なポイントになります。 以下は、直近半年間のApp Catalogの推移状況は以下になります。 リリース以降、昨年度までは日本の登録サイト数が非常に少ない状況でしたが、ACEへの登録が進んでおり、先月（2023年8月）に日本のサイト数が1,000を超過し、企業利用におけるSaaSやクラウド・アプリケーションについては、徐々にカバーできつつあります。 CASBの登録サイト数は、単純に登録数が多いだけで判断することなく、お客様が実際に利用されているSaaSやクラウド・アプリケーションをどの程度カバーしているかが重要になります。特に、最新で利用されているサイトが常に追加・更新されているかがポイントとなりますので、PoC（概念検証）等にて、Catoクラウドであれば、Cloud Appsダッシュボードで分類・未分類の比率を確認されることを推奨します。 また、未登録のサイトがあれば、Cato社へ登録申請を行うことも可能で、申請後、約2～3週間でACEへの登録が可能となっております。 強制（Enforcement） アセスメントによる評価・分析を実施した後は、各アプリケーション毎に必要なアクセスポリシーを自社内で決定し、そのポリシーを適用します。 Catoクラウドでは アプリケーション制御（Application Control） でポリシーを作成して、適用することができます。 CMA [Security]>[Application Control] 特定のアプリケーション/アプリケーションカタログ毎に、アクセス元（拠点やユーザなど）やデバイスポスチャなどを利用して、アクションを設定することが可能です。 例えば、Dropbox（Gmail）のダウンロードは許可するが、アップロードは許可しない。M365は、企業テナントIDでのみログイン可能とする（個人IDでのログインは許可しない）などです。 多くのお客様では、CASBで、いきなりアプリケーションを制限（Block）するのではなく、まず最初はモニタリング（MonitorおよびEvents）を行い、ユーザの利用状況を確認した上で、社内通知を行い、制限される場合が事例が多いです。 ここでは紹介しませんが、DLPのセキュリティオプションも同じアプリケーション制御（Application Control）にてポリシー設定を行います。 防御（Protection） 最後に、企業のセキュリティを危険にさらす可能性のある脅威やリスクからの防御についてです。 Catoクラウドでは、CASBだけではなく、統合された以下の各種セキュリティ機能を利用して、すべてのSaaSやクラウドアプリケーションを包括的に防御を行います。 次世代型ファイアウォール（NGFW） セキュア Web ゲートウェイ（SWG） 次世代型アンチマルウェア（NGAM） 不正侵入検知防御（IPS） 情報漏えい対策（DLP） リモートブラウザ分離（RBI） SaaS Security API 上記のセキュリティ機能・ツールを組み合わせることで、さまざまな脅威から包括的に保護することが可能となります。 まとめ 今回は、Catoクラウドのセキュリティオプション CASB および4つの基本機能である「可視化（Visibility）」「アセスメント（Assessment）」「強制（Enforcement）」「防御（Protection）」について解説を行いました。 SCSKでは、2021年からSASEの主要ソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit（通称 S4）」を定期的に開催しております。次回は2023年10月に開催を予定しております（2023年9月時点） Catoクラウドは、2019年より取り扱いを開始し、すでに多くのお客様の導入/運用をご支援させていただいております。 Catoクラウドの知名度向上に向けて、お客様導入事例の制作や、以下のFAQサイト運営を行っておりますが、この技術ブログ（TechHarmony）で、さらに皆様のお役に立て、Catoクラウドの知名度UPに少しでも貢献できればと考えております。 よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp
こんにちは、広野です。 Amazon DynamoDB は大量データからのキーバリューマッチングは超高速で素晴らしいのですが、クエリにかなりの制約があるので扱いが非常に難しいです。 実はセカンダリインデックスを使ったデータ削除もクエリ一発でできないので、スクリプトを組む必要があります。 今回はそんなスクリプトの紹介をしたいと思います。 やりたいこと 以下のサンプル DynamoDB テーブルがあるとします。 通常、category, user, id, checked の 4つの情報を元に検索をしています。※今回の説明で直接的に必要ない他の属性は割愛 categoryuser パーティションキー checkedid ソートキー id 属性(グローバルセカンダリインデックスのパーティションキー) AAA#user1 checked#001 001 AAA#user1 unchecked#002 002 AAA#user2 unchecked#001 001 AAA#user2 checked#002 002 AAA#user3 checked#005 005 ここで、以下のように id が 002 のデータだけを 削除 したいとします。 categoryuser パーティションキー checkedid ソートキー id 属性(グローバルセカンダリインデックスのパーティションキー) AAA#user1 unchecked#002 002 AAA#user2 checked#002 002 パーティションキーに格納されている category や user は大量にパターンがあるため、パーティションキー、ソートキーによる検索は難しい状況です。そのため、id をパーティションキーにしたグローバルセカンダリインデックスを作成し、該当のデータを削除したいと思います。 ところが、仕様上、 セカンダリインデックスで条件を指定したデータを 1本のクエリで削除することができません。 削除するには、一旦削除対象のデータを取得し、メインのパーティションキー、ソートキーを条件にしてベタに削除処理をループさせることになります。 上の例では、以下 2 つの条件で削除クエリをかけます。 categoryuser が AAA#user1 で、checkedid が unchecked#002 であるもの categoryuser が AAA#user2 で、checkedid が checked#002 であるもの さらに、追加要件として削除したい対象の id が複数件(大量)にあったとしましょう。上の例では id は 1件でしたが。 それをコードで一気に処理するには、以下のアルゴリズムが例なります。 削除対象の id をファイルにリストアップさせ、スクリプトに読み込ませる リストアップされた id 分、削除処理をループさせる 1つの id から取得したデータに含まれている categoryuser, checkedid のリストに対して、データを削除する（1件1件なのでループ) 言葉で書いてもわかりにくいので、以降はコードを見て頂いた方が早いと思います。 つくったもの 以下の Python スクリプトです。以下、パラメータは適宜修正してください。 TableName は DynamoDB テーブル名 FileName は 読み込みたいファイル名 DynamoDB に対してアクセスできること、Python、boto3 がインストールされていることが実行環境として必要です。必要に応じて DynamoDB のリージョン名は変更します。 import json import boto3 import decimal from boto3.dynamodb.conditions import Key dynamodb = boto3.resource("dynamodb", region_name="ap-northeast-1") table = dynamodb.Table(" TableName" ) # JSONファイルを読み込む with open(" FileName ") as f: data = json.load(f, parse_float = decimal.Decimal) # JSONデータの各行から指定した id のデータを取得する for row in data: id_value = row.get("id", None) if id_value: print(f"Searching for items with id: {id_value}") output = table.query(IndexName="id-index", KeyConditionExpression=Key("id").eq(id_value)) # 該当する項目があれば削除する for item in output.get("Items", []): print(f"Found item: {item}") # categoryuser がパーティションキー、checkedid がソートキー res = table.delete_item( Key = { "categoryuser": item["categoryuser"], "checkedid": item["checkedid"] } ) print(f"Deleted item: {item}") ※エラー処理は省略しています。 削除対象とする id は JSON データで以下のフォーマットでファイルとして用意します。実際に使ったときには他のデータも入っていたため JSON にしましたが、id だけなら単純な配列の方が適切だと思います。 [ {"id":"002"}, {"id":"005"}, {"id":"006"} ] これで、 削除したい id をファイルにリストアップすれば、DynamoDB に対してセカンダリインデックスベースで削除をかけられるようになりました。 まとめ いかがでしたでしょうか？ 本件、急ぎで必要になったため同僚や ChatGPT の助けも借りて即席でつくったものなんです。一応動いていますので、参考になるかと思います。 本記事が皆様のお役に立てれば幸いです。
管理者
