oViceは、使ってみるとかなりのトラフィックがかかる。常に、2～3Mbpsのネットワーク負荷がかかっている状態だ。
通信のトラフィック量が多いので、回線の状況や時間帯によってはoViceの挙動が安定しない。通信が安定しないと、oViceで何が困るかというと、
再参加機能がプアーな感じなので、人と人のコミュニケーションの目線だとストレスが大きい。とてもめんどくさくなるのがいけない。
「Text4Shell」というApache Commons Textのバージョン1.5～1.9にある脆弱性。この脆弱性を利用されると、意図しないリモートコード実行やリモートサーバ接続の危険性があるとのこと。「CVSS v3」では、「9.8」のクリティカル判定。MAXが10なので、数値としては、かなりの深刻度だ。
「Apache Commons Text」は、Javaのプログラムなどに組み込まれて使われるライブラリで、テキスト処理に特化した機能が集められたパッケージ。これ、地味に使っているかどうかの判定が難しい気がする。ソースコードで、importしているかの検索をすればよいが、ビルド時に使っているApache Cmmons Textのバージョンがいくつかによるので、管理されていないといちいち確認する必要がある。Githubなどにあるチェックツールを使っていれば簡単に検知できるみたいだが。
Log4Shellのような大事にはならないようだが、使っているかどうかが外形でわかりにくいこと、提供されてるプログラムの一部で使われている可能性もあることから、発見されないものが多く残りそうな気がする。
参考
Cloudflareもデータの保存と処理を行う地域を指定できる（限定できる）ようになったようだ。これについて、少しだけ考えてみた。
クラウドサービスが無国籍化した結果、データの保存場所を、国や地域（EUなど）が制限するようになった。大手クラウドは、地域ローカルにデータを置くような設定に舵を切っている。大きいところが解体されるわけでも、その国の業者が盛り上がるというわけでもなく、結局、資本と技術開発できる大手クラウドが強くなっている感じ。データは、大きい意味で国や地域のセキュリティに結び付くから制限したはずだけど、大手クラウド業者に牛耳られるところは変わらずか。
Cloudflare、データを処理する地域を制御する「Data Localization Suite」を日本で提供開始https://cloud.watch.impress.co.jp/docs/news/1441960.html
データの持ち出しや処理を制限すれば、その地域でオンプレミスのデータセンターでの運用や、地場のSaaS業者やIaaS業者が有利になるかと思ったが、結局はそうではなさそうである。使いやすいかどうかは別にして、大手のクラウドベンダーの方が技術者が多いので、そのサービスを使いたがる、その業者が地域最適したサービスを投入する、これでほとんど持っていかれるような形だ。サービス自体は、もともとグローバルで横展開されているわけで、保存されるデータを他地域への冗長化をせず、その地域の中から動かなくするだけでよい（簡単そうに言っているが、前提が複数エリア保存なので、そんなに簡単な設定変更じゃないはず）ので、展開はできるというわけだ。
この流れが、EUなどが青写真として描いていた姿かどうかはわからない。大手クラウドベンダーに牛耳られるのを防ぎたかったのであれば、外れている感じだ。
IoT家電で脆弱性が発見されての対応って、難しいんじゃないのか、と思う。技術的というよりも、使っている人的に。接続させないのが、いまのところなんだかんだ（セキュリティとか機能アップとかを考えると）と便利なんだろうと思ってしまう。
そのうち、家に、ファイアウォール的なセキュリティ機器を組み込まないといけなくなるような気がする。そうなると、持ち家・持ちマンションだとランニングコストが上がる。粗悪業者が紛れ込むとそれこそ大変なことが予見される。全部こみこみの賃貸が優位になるんだろうな、IoT完全対応とかで。IoT家電がフルでついていれば、ログインするだけでいい思えば、賃貸ではやっていけるか。セキュリティ対策も管理側がやればいいわけだし。利用料金が払えなくなったら、全システムが停止して、家としての機能がハコというだけになるような気もするが。
三菱の家電に脆弱性 炊飯器、冷蔵庫、エアコン、太陽光発電など広範囲 ユーザー側で対処をhttps://www.itmedia.co.jp/news/articles/2209/29/news179.html
IoT家電については、いろいろとウォッチしておく必要があるな。
B-Dashとのデータ連携で、SFTPを用いたデータ転送の方式がいまいち分かりにくかったのでメモ。そもそも、B-Dashのマニュアル自体が検索しても出てこない。アカウントがないと見れないところにしかないので、謎が多いというのはある。
前提として、オンプレ側のシステムから、B-Dash側にSFTPでデータを送り付ける（Push）するパターンでの検討だ。
下記のようなシステム構成でSCPによるデータ転送の説明がされている。このとき、謎なのが中間サーバと書かれている部分だ。
B-Dashシステム ←→ 中間サーバ（B-Dash側） ←インターネット→ 中間サーバ（利用企業側） ←→ 基幹システム等中間サーバとはあるのだが、これがなんなのかの説明がほぼなくわからない。何か用意されたアプリケーションを使って、それがデータ転送を、SFTPでやってくれるのかと思ったが、そうではない。アーキテクチャとして、基幹システムなどから直接データを送るのではなく、外部とやり取りをするための緩衝用としてのサーバを中間サーバと表現しているようだ。
例示では、WinSCPを利用したやり方が書いてある。WinSCPで秘密鍵と公開鍵を生成して、B-Dash側に鍵を登録する。利用する企業側の中間サーバと書かれているデータ転送用のサーバで、WinSCPを起動して、データをSFTPで転送する。WinSCPはコマンドラインでの動作もできるので、スクリプトを書くことでバッチ処理ができる。（SFTPで転送するためのポートはデフォルトのポート番号ではないので、注意が必要。ファイアウォールの設定変更も必要になってくる）
B-Dash側で取り込み時間の処理などの登録はあるが、中間サーバとか関係なく、SFTPで送信されて置かれたデータをシステム側に取り込むスケジュールの登録だと思われる。
パッと見、何かの取り込みのためのアプリケーションなどが用意されているように見えるのが分かりにくいポイント。結局データを送るためには、自前で、スクリプトなりシステムなりを用意する必要がある。この手のデータ連携では、データ転送用のクライアントアプリが用意されているサービスがあったりするので、それと同じと考えると間違いの元だ。
Google Analytics 4（以下 GA4）を設定していて、過去のアクセスデータをみていたら、3か月前のデータが選択できないことに気が付いた。
GA4のデータ保持期間は、最大で14か月なので、14か月分が蓄積されていると思っていた。設定を見てみると、保持期間がデフォルトで２か月となっており、これにより、2か月でデータが消えていた。設定を変えて、保存期間を延ばさないと1年分のデータの参照ができない。ちなみに選択できるデータの保存期間は、2か月か、14か月のどちらかのみ。
1. Google Analyticsで対象となる「プロパティとアプリ」を開く。
2. 「管理」（歯車マーク）から、「データ設定」の「データ保持」を開く。
3. イベントデータの保持のプルダウンで、「14か月」を選択する。ここが「2か月」だった場合は、2か月分のデータしか保存されていない。
4. 「保存」をクリックする。
「CVE-2022-3075」の脆弱性対応版、ChromeとEdgeがリリースされている。バージョンのつけ方がChromeとEdgeで異なるので、対応バージョンをメモする。
CVE-2022-3075の対応版のChromeバージョン
105.0.5195.102CVE-2022-3075の対応版のEdgeバージョン
105.0.1343.27ゼロデイの脆弱性がふえているのは気になる。新しいバージョンがリリースされていれば、自動更新なので楽ではあるけれど。ただし、ChromeやEdgeの再起動は必要。
参考
Chrome https://chromereleases.googleblog.com/2022/09/stable-channel-update-for-desktop.html
Edge https://docs.microsoft.com/ja-jp/deployedge/microsoft-edge-relnotes-security
1. Azureの管理コンソールにアクセスする。
2. すべてのサービスから、「サービス正常性」を開く。
3. サイドメニューから「計画メンテナンス」を選択する。通知がある場合には、サイドメニューの計画メンテナンスに、（1）のような件数表示がある。
4. メンテナンスの告知が表示されるので、選択して、内容を確認する。
5. 内容を保存する場合には、PDFで出力する。
AppServiceでも、個別のところにはなく、サービス正常性のところに通知がある。そして、複数のインスタンスがあるとき、どれの通知なのかわからない。
サービス停止を伴うものかどうかも、メンテナンスの内容を見てみないとわからない。（サービス停止を伴うもに出会っていないので、なんともいえないけれど）
Slackのフリープランが直近の90日分しか表示できなくなった。過去のSlackのデータが見れなくなると困るということになり、データのエクスポートをして、Excelで見れるようにした。
OSSのPythonのツールを使うので、Pythonを扱える環境が必要。めんどくさいので、Windows10のWSL2（Ubuntu）上で実行した。
1. Slackからデータをエクスポートする
2. エクスポートしたデータはZIP形式なので、展開する
3. Pythonのデータ変換ツールをGithubから落として、展開する（実行ファイルはPythonのソース１つだけなので簡単）。このツールには本当に感謝。
https://github.com/becky3/json_to_csv_for_slack
4. 変換ツールを実行して、チャネルごとのCSVデータにする。
一回のツール実行で、すべてのチャネルがCSVデータに変換された。
python converter.py /mnt/c/展開したエクスポートデータのフォルダ実行するときは、展開したエクスポートデータのフォルダをフルパスで記載する。CSVファイルの出力先は、コマンド実行のあとに表示されている。
5. Excelを空のブックで開く。
6. メニューの「データ」から「テキストまたはCSVから」を選択する。直接、CSVファイルを開くと、文字化けするので、「データ」から読み込ませる。
7. 4番で作成したCSVデータを指定して、開く。これでチャネルごとのシートになる。
8. CSVファイルの数だけCSVの読み込みを行う。
9. 最後はExcelのファイルを保存する。
Excelにしてしまえば、あとは検索でも加工でも、自由にできる。
おまけ。試行錯誤して、失敗した／あきらめた方法。
・ExcelのPowerQueryでJSONファイルを読み込ませる。
→これは、１つ１つファイルを指定していけば、読み込みできた。
ただ、フォルダを指定して、結合して読み込ませると、JSONの形式でエラーになり、取り込めず断念。
・PowershellでCSVファイルに加工する
→結構、めんどくさい。時間かかりそうなので、やめた。
・JSONをSQL Serverに取り込んでから、ExcelやAccessで活用
→JSONファイルをSELECT文で操作はできるが、DBに取り込むところがめんどくさい感じ。
先にテーブル設計して、、、ならばいけそうだったが、時間がかかるのでやめた。
・Google Spreadsheetに取り込む
→GAS製の有料、無料のツールがあった。
GASで自作も考えたが、なんかめんどい感じだったので諦めた。
・別のツールにエクスポートデータを取り込み
→そのツールを管理する手間がある。
お手軽ではない。
悪意があるかどうかは別にして、TikTokのアプリがキーストロークをサブスクライブ（購読？読み取り？）するオーバーラップをしていることが問題だ。
TikTokのiOSアプリも「キーロガーと同じような動作」と開発者が指摘
https://www.itmedia.co.jp/news/articles/2208/22/news087.html
アプリによって、動作は異なるけれど、アプリ内でHTMLのリンクをクリックすると、そのアプリ内でウェブサイトを開く場合と、chromeやSafariなどの別ブラウザに移動する場合がある。アプリ内ではなくて、ブラウザが起動してくれるのであれば、ブラウザ側の制御になるので、そんなに問題はない。アプリ内で、ウェブサイトがレンダリングされるときは、今回のTikTokのように、他のウェブサイトのレンダリング時にかぶせるように、JavaScriptで操作されることが問題。キーストロークを取得するような動作は、悪意を疑われても仕方ないような気がする。特に、TikTokであれば・・・なおのこと。
まぁ、TikTopは使わないので関係がないと言えば、関係ない。そもそも信じられないので、TikTokを使わないので。
なんでもかんでもスマホアプリを使う世の中になっているので、こういうセキュリティ的な問題は続々と判明しそうだ。必要なアプリ、必要のないアプリを見極めて行かないといけない。