アフィリエイト広告を利用しています
検索
<< 2024年01月 >>
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
最新記事
タグクラウド
カテゴリーアーカイブ
ファン
最新コメント
プロフィール
ゼロから始めるシステム開発さんの画像
ゼロから始めるシステム開発
 こんにちは!ナビゲータのEVEです。各種研究室を用意し、次期EVEシステムを製造しようと日々頑張っています。現在一番力を入れているのが、資金調達です。このブログもその一環ですので、ご協力いただければ嬉しいです。

2024年01月21日

DBへ接続するためのユーザIDとパスワードの管理方法の最終検討 〜システム開発研究室〜


 こんにちは!
 ナビゲータのEVEです。
セキュリティ.jpg
 昨日までは、DBへ接続するユーザーIDとパスワードを管理する方法について検討してきましたが、ブログアップロード後ChatGPTから以下の指摘がありました。

セキュリティ上の理由から、通常はプロジェクト内で利用するファイルには相対パスを使用する方が一般的です。
?可搬性(ポータビリティ)
 相対アドレスはプロジェクト内のファイルやディレクトリの関係性を考慮して指定されるため、プロジェクトの構造が変更された場合でも相対パスが適切に動作します。絶対パスを使用すると、プロジェクトを別の場所に移動させたり、他の環境にデプロイする際に手動でパスを修正する必要があります。
?セキュリティ
 絶対パスを直接指定すると、不用意にシステム内のファイルにアクセスするリスクがあります。相対パスを使用することで、必要なファイルやディレクトリへのアクセスを制限しやすくなります。
?プロジェクトの可読性とメンテナンス性
 相対パスはプロジェクト内の構造を反映しているため、コードが他の開発者やメンテナンス担当者にとって理解しやすくなります。絶対パスを使用すると、どのファイルやディレクトリが指定されているのかを理解するのが難しくなります。


 今回、 etc に設定し利用しようとしてるのですが、以上の指摘だと require_once の記述が複雑になります。しかも、?が気になります。以上のようなことを考慮すると、配置先は限定され、?@と?Aを利用するのは難しくなります。

?@INIファイル
?AJSONファイル
?B環境変数
?CPHPファイル


なお、以上に ChatGPT がプロジェクトと記述しているその内容をいろいろと調べた結果、 var 配下は一応 Apache は認識でき、それをプロジェクトと言って問題ないようです。但し、その調査は、十分し尽くしたと言えるレベルではないので、後日訂正するかもしれません。

[最終検討]
 ChatGPTとの長い時間会話した結論ですが、環境変数によりDBへ接続するためのユーザーIDとパスワードを設定し、設定したファイル値を $_SERVER で取得する仕様にしようと現在は、考えています。その場合、Apacheルート配下へDB接続するユーザーID、パスワードを管理するファイルを配置する必要はありません。しかも、$_SERVER変数として、プロジェクト内ならどこからでも取得することが可能です。ただ、この場合の問題は、設定するファイル名が限定されます。それは、ちょっと、いただけません。

[あとがき]
 DBへ接続するためのユーザIDとパスワードの管理方法については、問題はあるものの、今回はこれで、最後としたいと思います。$_SERVER変数への設定は、現在ファイル名が限定されるという問題はありますが、SALT値を導入することができれば、セキュリティが格段と上がります。という観点から言うと、以上の検討はEVEシステムでの利用となりそうです。ただ、Prototype EVEでは、ファイル名が限定される以上の方法は問題があると考え、別の方法で対応します。ここで、それを書こうとしたのですが、セキュリティ上問題があると思われますので、この辺までとさせていただきます。

 では、また!

2024年01月20日

サーバーでのユーザID/パスワードの管理方法 〜システム管理研究室〜


 こんにちは!
 ナビゲータのEVEです。
ハッカー.jpg
 昨日までは、DBへ接続するためのユーザーIDとパスワードを ハードコーディング する場合、どうしたらいいのかという検討をしてきました。
 本日は、同ユーザIDとパスワードをどのような形で管理をしたらいいのか具体的な検討に入りたいと思います。

[管理方法]
 ChatGPTは管理する形式について、一例ですが、以下の方法を提案しています。

?@INIファイル
?AJSONファイル
?B環境変数
?CPHPファイル


 以上のファイルをどのように管理するのかその保管方法について以下の内容で提案しています。

1)ファイルのアクセス権限
2)機密情報の暗号化
3)ファイルの場所
4)サーバーのログに記録されないように



[検討]
 ファイルを指定して、中身に定義している変数の内容を取り出すのはどの形式のファイルでも同じようです。そのため、プログラミングの 生産性 という意味では、?@〜?Cにおいては、同じと言うことになります。それでは、次に1)〜4)の セキュリティ について考えて見ましょう。
 1)は当然リリース時に実施します。 所有者はApache でそれ以外のユーザーに利用させないようにします。現在は以上のように設定していますが、EVEシステムでは 構成管理システム で自動で行う予定としています。
 2)はどうでしょうか?DBへ接続するユーザーとパスワードのユーザを格納するファイルを 暗号化 した場合、当然 復号 しなければ利用できません。それを、データベースを利用するたびに実施するのでしょうか?この方法は現実的ではありません。私の作るシステムでは利用は難しいようです。
 3)ファイルの格納場所ですが、どこがいいでしょうか、 Windows ユーザーにはあまり知られていませんが、Linux系OSの各フォルダには役割が決まっています。この機会に、 Ubuntu で利用している各フォルダの役割についてChatGPTに解説をしてもらいましょう!

?/bin (Binary):
役割: このディレクトリには、システムの基本的なコマンドやプログラムが格納されています。システムが実行されているときに必要なコマンドがここにあります。
?/boot:
役割: システムの起動に必要なブートローダ、カーネルイメージ、および関連するファイルが格納されています。ブートプロセスで使用されます。
?/dev (Device):
役割: デバイスファイルが格納される場所です。デバイスファイルはハードウェアや仮想デバイスと通信するための特殊なファイルです。
?/etc (Editable Text Configuration):
役割: システムの設定ファイルが格納される場所です。ほとんどのシステムの設定はこのディレクトリ内のファイルで管理されます。
?/home:
役割: ユーザーホームディレクトリがここに格納されます。各ユーザーはここに自分専用のディレクトリを持ち、そこに個人用のファイルや設定が保存されます。
?/lib (Library):
役割: 共有ライブラリが格納される場所です。システムとアプリケーションプログラムが使用する共有のライブラリがここにあります。
?/media:
役割: 可能な場合には、リムーバブルメディア(USBドライブ、CD-ROMなど)が自動的にマウントされるディレクトリです。
?/mnt (Mount):
役割: 一時的にファイルシステムをマウントするためのディレクトリです。通常、外部のデバイスやネットワークファイルシステムをここにマウントします。
?/opt (Optional):
役割: オプションのソフトウェアパッケージが通常ここにインストールされます。これにはサードパーティのアプリケーションが含まれます。
?/proc (Process):
役割: カーネルとプロセスに関連する情報が仮想ファイルシステムとして提供されます。実行中のプロセスやシステムのステータスにアクセスできます。
?/root:
役割: rootユーザーのホームディレクトリです。通常のユーザーのホームディレクトリは/homeにあります。
?/run:
役割: 実行時に生成されるデータやプロセスの一時ファイルが格納されます。一時的なデータやPIDファイルがここに配置されます。
?/sbin (System Binary):
役割: システムの管理者が使用する管理コマンドやシステム設定に必要なプログラムが格納されています。
?/srv (Service):
役割: システムが提供するサービスに関連するデータが格納される場所です。例えば、Webサーバーのドキュメントルートがここに配置されることがあります。
?/sys (System):
役割: カーネルとハードウェアに関する情報が提供されるディレクトリです。/procと同様に、仮想ファイルシステムです。
?/tmp (Temporary):
役割: 一時的なファイルが格納される場所です。通常、システムが再起動するときに削除されます。
?/usr (Unix System Resources):
役割: システムのほとんどのプログラムやファイル、ライブラリがここに配置されます。通常は共有されるリソースが格納されるディレクトリです。
?/var (Variable):
役割: システムの変動するデータ(ログファイル、データベースファイル、メールなど)が格納される場所です。頻繁に変更されるデータがここに保存されます。


以上の調査結果から、 etc がふさわしいようです。
 4)については、セキュリティにおいてログの管理方法を検討する機会があります。その時にどうしたらいいのか検討したいと思います。そのため、ここでの検討は省略します。

[あとがき] 
 今日も時間がきましたので、この辺までとさせていただきます。

 現在、クラスを製造していますが、そろそろ、文字クラスの製造の終わりが見えてきました。以前、以下のクラスを作ると話していました。

■DB関連class ← 作成済み
・データベース検索メソッド
・Fetchメソッド
・テーブル一覧取得メソッド
・SQLdbqueryメソッド
・レコード追加メソッド
・レコード更新メソッド
・レコード削除メソッド
・トランザクション開始メソッド
・コミットメソッド
・ロールバックメソッド
・レコード件数取得メソッド
・エラーメッセージ取得メソッド
・エラーNo取得メソッド
・トランザクション変数取得メソッド


■ファイルClass
・ファイル取得メソッド
・ファイルコピーメソッド
・ファイル書き出しメソッド
・ファイル削除メソッド
・ファイル読込メソッド
・コンテンツ取得メソッド

■数値Class
・数字チェックメソッド

■文字Class
・配列⇔文字列変換メソッド
・乱数取得メソッド
・文字列編集メソッド
・文字列部分取り出しメソッド
・指定文字列検索メソッド
・指定文字列削除メソッド
・html⇔文字列変換メソッド

■時間Class
・現在日付取得メソッド
・日付取得メソッド
・タイムスタンプ編集メソッド

■セキュリティClass
・SHA3ハッシュ値取得メソッド

■配列Class ← 作成済み
・配列結合メソッド
>

■メールClass
・メール送信メソッド

■メッセージClass
・メッセージ出力メソッド
・エラーログ出力メソッド


ただ、予定が変わり、現在は、文字クラスなら、Prototype EVEで利用していた関数をすべてクラスに変更しています。理由は、文字クラスならそのクラスで文字列に対する機能を プロパティ メソッド 等という形で提供していることを作っている途中で悟ったからです。そのため、配列Classは1つしかメソッドを記述していませんが、それ以外にもメソッドを製造しています。
 その他のクラスも同様に製造する予定です。そのような製造方針で作っていて、2月末日までに製造が完了するかどうか、あやしくなってきました。これから、速度を上げて製造していきたいと思います。

 では、また!

2024年01月19日

サーバーでのユーザID/パスワードのハードコーディング 〜システム開発研究室〜


 こんにちは!
 ナビゲータのEVEです。
ワーク.jpg

 昨日までは、Webサーバー側からDBに接続するための、ユーザーID、パスワード保存するためにどんなセキュリティがあるのか検討し、そのセキュリティの問題点について考えてきました。そして、パスワードをPHPから定期的に更新することについては、リスクの軽減になるが、同ユーザーIDとパスワードの保存方法について細心の注意が必要だと ChatGPT から指摘がありました。同4項目の指摘について、現在のPrototype EVEでの対応方法について考えてみました。?〜?までは見通しがたったのですが、?のユーザーIDとパスワードの ハードコーディング について問題が解決できていないので、引き続き検討していきます。

?権限の過剰な付与:
?SQLインジェクションのリスク
?暗号化されていない通信
?ハードコーディングの問題:



[ユーザID、パスワードのハードコーディングの検討]
 では、ChatGPTはどのような保管方法が高いセキュリティで保護されるといっているのでしょうか?

 セキュアな設定ファイルは、機密情報(データベースのユーザー名、パスワード、APIキーなど)を保持し、アプリケーションがそれらの情報を安全に利用できるように設計されたファイルです。以下は、一般的なアプローチとファイルの形式のいくつかの例です。ただし、重要なことは、どのようにそれを利用し、保管するかです。

?@INIファイル
 INI形式のファイルは、設定情報をキーと値のペアとして保存するのに適しています。例えば、config.iniというファイルを作成し、そこにデータベース接続情報を保存することができます。
?AJSONファイル
 JSON形式のファイルもキーと値のペアを使用して構成でき、設定情報を格納するのに適しています。
?B環境変数
 環境変数を使用して機密情報を設定する方法もあります。これは特にクラウド環境などで一般的です。
?CPHPファイル
 PHPファイルに設定情報を含めることも可能です。ただし、この場合はファイルが外部から直接アクセスされないようにするなどのセキュリティ対策が必要です。


 では、重要だといっていることについてChatGPTに再質問をしてみました。

1)ファイルのアクセス権限
 設定ファイルには機密情報が含まれる可能性があるため、適切なファイルアクセス権限を設定する必要があります。これにより、不正なユーザーやプロセスからのアクセスを制限できます。
2)機密情報の暗号化
 パスワードなどの機密情報は、可能な限り暗号化された形で保存されるべきです。ファイルそのものは平文であるため、機密情報を保護するためには別途暗号化の手段を検討する必要があります。
3)ファイルの場所
 セキュリティの観点からは、設定ファイルは外部から直接アクセスされないように配置されるべきです。また、Webサーバーなどが公開するディレクトリ内には配置しないようにしましょう。
4)サーバーのログに記録されないように
 設定ファイルには機密情報が含まれるため、サーバーのログに出力されることがないようにすることが重要です。

 安全な設定管理は、設定ファイルだけでなく、それを扱うアクセス権、暗号化、およびアプリケーションの実装にも依存します。


最初の解答は、セキュリティのことは一切考えておらず、DBサーバーへのアクセスするためのユーザーIDとパスワードを格納しやすいファイルとして紹介してくれたようです。この場合、?@?Aは、DBサーバーへのアクセスするためのユーザーIDとパスワードを保管する方法としては不適切だと思ったのですが、「3)ファイルの場所」を見てはっとしました。当該ファイルを Apache のルートフォルダに設定する必要はないのです。もしかしたら、etcでもいいかもしれません。それを考えたら、別に PHP ファイルで保管する必要はないようです。
 なんで、こんなこと今まで気づかなかったのでしょうか?これが、1人で開発する場合の限界です。ただ、今は、ChatGPTがいます。何かあればChatGPTに相談し、問題点を洗いだし、その問題を解決しています。

[あとがき]
 今日も時間となってしまったので、この辺までとさせていただきます。
 このような検討をしていると、いろいろな部分に配慮しないといけないことが分かります。
 「4)サーバーのログに記録されないように」とありますが、これについて、Microsoft社がやってしまったことがありました。それは、システム障害が発生したとき、公開鍵暗号方式の秘密鍵をログに書き込んでしまったのです。そして運悪く、そのログを中国人ハッカーに見られてしまったということがありました。そのあとは、ハッキングのし放題です。多分ですが、機密情報を窃取されたのでしょう?

 現在は、セキュリティは、必要不可欠なもので、リリースする前には、セキュリティチェックは必須です。ただ、Microsoft社のような大企業になると、システムも巨大で、かつ、それの全てを監査するのは難しいと思われます。結局は、問題が発覚してからの対処になるのでしょうか?どうしたら、いいのか引き続き考えていきたいと思います。

 では、また!

2024年01月18日

Prototype EVEの脆弱性への対応検討 〜システム開発研究室〜


 こんにちは!
 ナビゲータのEVEです。
進歩.jpg
 昨日は、 Prototype EVE のセキュリティリスクについて検討しました。ただ、その検討結果を ChatGPT にお聞きしたところ、セキュリティ上問題があるとの回答があり、本日再検討することになりました。では、ChatGPTは昨日の検討について、どんな問題があると指摘しているのでしょうか?

[ChatGPTからの指摘]
 ChatGPTは、以下の問題点を指摘しています。

?権限の過剰な付与:
 rootユーザーはMySQLデータベースの管理者であり、非常に高い権限を持っています。PHPスクリプトがrootユーザーとして実行されると、そのスクリプトがデータベースに対して行う全ての操作に対して、rootユーザーの権限が与えられます。これにより、権限の制限が不十分である場合、意図しないデータベースの変更が発生する可能性があります。

?SQLインジェクションのリスク
 PHPスクリプトがユーザーの入力を直接クエリに組み込む場合、SQLインジェクションのリスクが高まります。攻撃者は入力を操作して、意図しないクエリを実行させる可能性があります。これは特に、rootユーザーとして実行される場合には深刻な問題となります。

?暗号化されていない通信
 PHPスクリプトがMySQLデータベースに接続する際に、パスワードなどの情報が暗号化されていない通信経路を介して送信される可能性があります。これは、ネットワーク上でデータが傍受されるリスクを孕んでいます。

?ハードコーディングの問題:
 PHPスクリプトにrootユーザーのパスワードがハードコーディングされている場合、ソースコード自体が機密情報を含んでいることになります。このファイルが不正にアクセスされれば、データベースへのアクセス情報が漏洩します。



[ChatGPTからの指摘]
 聞いている問題点は、 PHP からDBのユーザーIDとパスワードを変更するに際し、セキュリティリスクがあるということへの質問だったのですが、ちょっと、的がはずれているようです。その原因について深掘りして聞いてみると、更新すること自体はセキュリティリスクの軽減になるのですが、そのユーザーIDとパスワードを管理する方法について問題視しているようです。
 ChatGPTの指摘を、Prototype EVEではどうなのか考えてみたいと思います。

 ?ですが、 root権限 では、 権限が高すぎる といっています。これについては、実行するためのユーザーを複数作り、この問題に対応したいと思います。
 ? SQLインジェクション ですが、プログラム的に対応しているので、問題ないと考えています。
 ?Webサイトを構築する場合、 3階層 にします。クライアント、Webサーバー、そしてDBサーバーです。そして、WebサーバーはDMZ上に存在し、DBサーバーは社内にあるのが通常です。ここでは、そのWebサーバーとDBサーバーの通信が 暗号化されていない ことを、問題としています。通常は、 DBサーバーとの通信をWebサーバーに限定し、ポート番号を制限する というところまでですが、それだと、盗聴された場合、通信の内容が垂れ流し状態になります。Webサーバー( PHP )とデータベースサーバー( MySQL )間を、 SSL/TLS で通信させる方法があるので、それを検討したほうがいいようです。
 ?は仕方がありません。Webサーバーからアクセスする場合のユーザーIDとパスワードなので、データベースに格納することはできません。じゃ、どこに格納するかというとやはり、Webサーバー上のどこかということになります。

[あとがき]
 また、長くなってしまったので、本日は、ここまでとします。なお、?〜?の問題については、解決の見通しがたったので、明日は?の ハードコーディング の問題について検討を進めたいと思います。

 ?ハードコーディングの問題はどうしても、問題は問題として認識し、それでもWebサーバーにユーザIDとパスワードをハードコーディングしなければなりません。明日は、この リスクを保有 するに際し、どう対応するのか検討をしたいと思います。

 では、また!

2024年01月17日

Prototype EVEの脆弱性 〜システム開発研究室〜

 こんにちは!
 ナビゲータのEVEです。
ハッカー.jpg
 一気にと行きたいのですが、地道にプログラムを製造しています。
 中には、システム的に定義されているんだけれど、実際に使われておらず、かつ、どうやって使ったらいいのか不明だったモノがあったり、思ったより大変です。ただ、使われておらず、プログラムを見ても使用用途が分からないものは、どうしようもないので、削除しています。

[システムの脆弱性]
Prototype EVE 脆弱性 を見つけてしまいました。それは、データベースに接続するためのユーザIDと、パスワードについてです。
 Prototype EVEでは、システムを動かすのに、 root権限 で実行しているのですが、それは、当然、Webサーバー側に設定しています。そうしないと、データベースにアクセスできませんから・・・。開発をし始めた2004年は、テキストファイルで一元管理していたのですが、それだと、アドレスバーから当該ファイルを指定した場合、その中身が見えてしまいます。それでは、まずいので、格納ファイルをPHPファイルに変更しました。実は、それで満足し、現在まで至っています。

[どんな脆弱性]
 Prototype EVEでは、データベース接続用のユーザIDとパスワードは 定数 で管理しています。そのため、 ハッカー がPHPファイルをアップロードする手段があり、かつ、ユーザIDとパスワードの定数が分かった場合、echoとかprintでブラウザから確認できてしまうのです。

[現在の対策]
 以前自宅にサーバーを設置していたときのことですが、そのときは、サーバーの ハードニング を行い、Prototype EVEからしか、ファイルの更新や、データベース操作ができないようにしていました。それに加えて、Prototype EVEからアップロードするファイルを限定していました。だから、問題ないとは思うのですが、自分ができないと思っても、できちゃう人はできちゃうんですよね・・・。

[今後の対策]
 今後の対策ですが、 ChatGPT と会話をしていて、いい方法が思いつきました。
 データベースのユーザIDとパスワードなので、データベースに格納はできません。だから、今まで通り、ファイルで管理をするのですが、データベースにアクセスする場合は、ユーザIDとパスワードに SALT値 をつけたものをユーザーIDとパスワードとして登録するのです。そうすれば、定期的に、SALT値を変更するだけで、ユーザIDとパスワードを高いセキュリティレベルで守ることができます。

[あとがき]
 実は、問題点もあります。それは、最初どうするか?
 普通にやるとすれは、ユーザID、パスワードとSALT値を用意し、用意したユーザIDとパスワードにSALT値を付加し、 SHA3 ハッシュ値 を取った値を、MySQLのユーザIDとパスワードにするという方法です。最初だけだからいいのですが、ちょっと、間抜けです。やはり、これも、EVEシステムでユーザーを管理する方法と同様に、モードを用意し、通常モードで安全に稼働するようになったら、セキュリティの高いモードで管理するという方法がいいでしょうか?
 ただそれだと、EVEシステムのフレームワークができてからということになり、Prototype EVEで運用している時はどうしましょうか?

 頭が痛い問題です。

 では、また!

2024年01月11日

システムコンセプト


 こんにちは!
 ナビゲータのEVE Sunです。
設計.jpg
 今日から、システム製造の再開です。以前の開発体制に戻すので、平日はゴリゴリと製造するのではなく、隙間時間を利用し、1日1〜5メソッドの製造をしていく予定です。
中小企業経営政策 で時間が思った以上に取られましたが、その間、いろいろとシステム製造について考える時間を持つことができました。その考えることにより6、7月クラス関連の見直しの作業が必要なくなるかもしれません。ただ、オブジェクト指向言語でシステムを作ったことがないので、想像通りにならない可能性はありますが・・・・。

■開発スケジュール
01月 クラスの製造
02月 クラスの製造
03月 Yahooダウンロード処理の製造
04月 クローニングデータ抽出条件登録・修正・削除処理の製造
05月 Yahooデータ抽出処理の製造
06月 クラス関連の見直し
07月 クラス関連の見直し
08月 ユーザ管理システムの製造
09月 権限管理システム製造
10月 メッセージ管理システムの製造
11月 パラメータ管理システムの製造
12月 コンテンツ管理システム



[ログインシステム製造後]
 クラス関連の製造を除けばかなり余裕をもったスケジュールです。 捕らぬ狸の皮算用 だと言われるかもしれませんが、ついついその先のことを考えてしまいます。
 以前、EVEシステムは以下のようなコンセプトで製造するという話をしています。


?@システムはユーザの利益のために
?Aシステムそのものがドキュメント
?B全てをシステムで管理する
?C1人でシステムを運用する
?Dすべての操作を一つの手順で


以上の全体のアウトラインは変わっていないのですが、細かい部分が少しずつこの時考えたものと違ってきています。特に?Dです。

[?Dすべての操作を一つの手順で]
 ここでいっていることは、データベースに関する開発のことを言っています。
 昔は、小さいテーブルなら普通に製造できるのですが、そのテーブルのデータ件数等が大きくなると製造方法を工夫しなければなりません。テーブルのデータ件数が多くなると検索スピードが遅くなるからです。
 ただ、ここでは、 テーブルのデータ件数が大きくても、小さくても同じ製造方法になるように工夫したい といった目標でした。
 この工夫なのですが、今まで製造したことがなく、かつ、他のシステムでも見たことがありません。しかも、このシステムを脳裏にイメージしようと試みるのですが、ぼんやりと靄がかかったような状態です。
 今までに、システムを作る段階で、靄がかかったような状態だったときはありません。完ぺきにイメージできていれば、システムを作ることは可能ですし、そうでなければシステムを製造することができませんでした。そういう経験からいうと、システムは作れないと言うことになります。

[今まで通りに作ってみる]
 どんなシステムなのか、解説しようと思うのですが、複雑すぎるうえ、自分でもきちんとイメージできていないので、説明できません。
 以上のような状況で、EVEシステム開発当初は今まで通りにデータベース関連まわりを作ってみようと思います。ただ、ある程度システムが成熟してきたら、新データベースにアクセスするメソッドを作り、 画面からボタン一つで、新しい構成にデータベースを再編する ようにしたいと考えています。

[あとがき]
 最初っから想定しているシステムを製造したほうが、バグがないなんて言う人もいるのですが、頭の中でシュミレーションすると、どうも、作ったから終わりという分けにはいかないようです。作ってみたけれど、速度が出ないといった場合も、新データベースを再構成しなければいけないというタイミングが出てきそうなのです。だから、どっちみちそうなる運命なら、絶対動く感じでデータベースを製造し、その後、再構成するでもありかなって思うようになりました。しかも、今回プログラムはオブジェクト指向で作るので、必要な部分だけ継承して作ることができます。
 これ、いつになるのか分かりませんが、製造が完了し、思ったパフォーマンスが出たら公開し、どんなシステムなのか概要を解説したいと思います。

 では、また!

■プロローグ〜EVE〜 [YouTubeでの稼ぎ方研究室] 2023年8月5日
https://fanblogs.jp/bahamuteve/archive/34/0

2024年01月09日

エモテット 〜セキュリティ研究室〜


 こんにちは!
 ナビゲータのEVEです。
ハッカー.jpg
 本日は、2014年から流行している エモテット というマルウェアについて御紹介します。 マルウェア とは、 ウイルス ワーム トロイの木馬 スパイウェア アドウェア ランサムウェア など聞いたことがある悪意のプログラムの総称です。
 それでは、どんなマルウェアなのでしょうか?情報が IPA から提供されているので、確認してみましょう!

[どんなマルウェア]
 エモテットは、いろいろな使用の方法はあるようですが、多くの場合は、個人の銀行関連の情報、例えば、口座のアカウント情報、クレジットカードに関する情報などを盗聴し、金銭を搾取するために利用しています。2014年から未だに流行している背景には、 金銭的なインセンティブ エモテットの技術的な進化 があるようです。

[どうやって感染する?]
 感染方法は、 ソーシャルエンジニアリング です。主にメールが利用されることが多いようです。IPAで紹介されている方法は、メールに添付されたWordやExcelのマクロを使った感染方法です。ただ、これは一例であり、感染させようと思うなら、メール本文からURLをたどる方法も使用するかもしれませんし、USBなどを使用して感染させるグループもあるかもしれません。これは、あくまで一例なので、 ゼロトラスト のセキュリティ意識で対応することが大切です。

[感染症状]
 クライアントが感染した場合発見するのは非常に困難らしいです。ただ、以下の症状が現れることがあります。

?@パフォーマンスの低下
?A不審なネットワーク活動
?B異常なプロセスやファイルの存在
?C不正なメールの送信



[対策]
 では、対策については、 ChatGPT に解説してもらいましょう!


?セキュリティソフトウェアの使用
 信頼性の高いアンチウイルス・アンチマルウェアソフトを使用し、シグネチャベースの検知だけでなく、ヒューリスティック分析や機械学習などの高度な検知技術を備えたソフトウェアを選択します。
?システムとソフトウェアのアップデート
 オペレーティングシステム、ブラウザ、セキュリティソフト、その他のソフトウェアを最新の状態に保ちます。セキュリティパッチやアップデートが提供されたら早急に適用します。
?スパムメールへの警戒
 不審なメールやリンクを開かないようにし、特に送信者が不明で、不審な添付ファイルが含まれている場合には注意が必要です。
?ネットワークトラフィックの監視
 不審なネットワークアクティビティを監視し、異常なトラフィックが検出された場合は早急に調査と対策を行います。
?ユーザー教育
 ユーザーに対してセキュリティ意識を向上させるための教育を行います。不審なリンクや添付ファイルには慎重になるよう啓発します。
?ネットワークセグメンテーション
 ネットワーク内でセグメントを作成し、セグメントごとにアクセス制御を強化することで、エモテットの感染が広がりにくくなります。


 ちなみに、IPAからは以下のような対策が提案されています。

・業務で使用しない形式のファイルが添付されたメールは、受信を拒否する。
・業務でマクロ機能を使用しない場合は、無効化する。
・送信ドメイン認証を活用したメールフィルタリングを実施する。
・職員(ユーザー)に対して、不審なメールに関する注意喚起やセキュリティ教育を実施する。
・職員(ユーザー)が不審なメールを受信した場合や、誤って添付ファイルを開いてしまった場合の相談・報告窓口を設置し、不測の事態に迅速に対応できるように準備しておく。

〜情報提供元〜 IPA

 なお、ウイルスソフトを導入していれば安心というわけではなく、そのウイルス対策ソフトを回避するエモテットもあるようです。特に、 パターンファイル型のウイルス対策ソフト は発見が遅れる可能性があります。そのため、ChatGPTも指摘している通り、以下のタイプのウイルス対策ソフトの導入が望まれます。

?@ヒューリスティック分析
?Aビヘイビア分析
?Bサンドボックス分析
?C機械学習



[あとがき]
 対策したから安心なんてことはありません。狙われたら、まず90%以上の確率で感染してしまうと考えた方がいいでしょう?そのため、ChatGPTが指摘するような対策は当然行うとして、感染した場合、どのようなことをするのか事前に決めておくことが大切です。
 加えて、感染後すぐに普及し、業務を再開できるような体制をとることが重要です。

 攻撃者はかなり頭がいいのは分かるのですが、その頭脳・・・。公共の利益に利用してほしいと思うのは私だけではないと思います。

 では、また!

■Emotet(エモテット)の概要(IPA)
https://www.ipa.go.jp/security/emotet/index.html

■Emotet(エモテット)攻撃の手口(IPA)
https://www.ipa.go.jp/security/emotet/attack.html

■Emotet(エモテット)対策(IPA)
https://www.ipa.go.jp/security/emotet/measures.html

2024年01月07日

コンピュータウイルス 〜セキュリティ研究室〜


 こんにちは!
 ナビゲータのEVEです。
ウイルス.jpg
 久しぶりに、ブログの更新が太陽が落ちてからになってしまいました。 中小企業経営政策 の勉強の仕方にチョット迷いがあったからなのですが、やっと、勉強の方向性が定まりました。明日から、地に足を着いた活動ができそうです。
 それでは、夜も更けてきた本日は、先日 X (旧ツイッター)につぶやいた、コンピュータウイルスの記事について調べて見たいと思います。

[ナゾロジーで紹介されていたウイルス]
 『ヤバイ「コンピュータウイルス」5選』ってタイトルだったので、本当にやばいな〜って思ってしまいました。ただ、調べて見ると、紹介していたウイルスは過去のモノで、昨年2023年に流行はなかったようです。
 紹介されていたウイルスは、下記の通りです。それと同時に、流行した年を入れておきました。

サッサー(Sasser)(2004年流行)
コードレッド(Code Red)(2001年流行)
ゲームオーバーゼウス(Gameover ZeuS)(2011〜2014年流行)
ラブレター(LOVELETTER)(2000年流行)
マイドゥーム(Mydoom)(2000)年流行


確かにやばそうなウイルスではあるのですが、防御する技術者も学習し、昨年2023年には感染報告はありません。しかも、ほとんどのウイルスは プラットフォームに依存 するものばかりなので、対策したことにより消えたのと同時に、そのプラットフォーム自体も経年により消失し、そして、ウイルスがなくなったといった感じです。

[調べ終えて]
 調べ終えての感想ですが、『ヤバイ「コンピュータウイルス」5選』って記事なのですが書くネタがなくってアップロードした記事かなって感じです。
 記事の公開日は、2024.01.02 TUESDAYなので、多分そうでしょう?タイトルを見てドキドキしてしまいましたが、ドキドキするほどのモノではなかったようです。
 このウイルスが感染していたころは、システムは動けばいいと言ったもので、セキュリティまで考えてシステムは製造していませんでした。
 ただ、今振り返ると、2000年に入った直後だと思います。あるお客さまのところに行って、セキュリティについて聞かれたとき。セキュリティは現在使用している フレームワーク が保証していますと言った記憶があります。確かに仕事をする建前上そう言わざるを得なかったのですが、今から考えると、そのプラットフォームも怪しいところがいくつかありました。ただ、そのあやしさを当時の自分は気づいていなかったような気がします。しかも、当時、Yahooとか、公的機関とかしょっちゅうハッキングされていたので、そういう時代だったのかもしれませんが・・・?

[2023年のはやり]
 2023年にはやったウイルスは一体何だったのでしょうか?


エモテット:エモテットは、他のウイルスを拡散する強力なマルウェアです
JS/Adware.Agent:悪意のある広告を表示させるアドウェアの汎用検出名
HTML/ScrInject:HTMLに埋め込まれた不正スクリプト
DOC/Fraud:詐欺サイトのリンクが埋め込まれたDOCファイル
JS/Packed.Agent:パックされた不正なJavaScriptの汎用検出名
HTML/FakeAlert:偽の警告文を表示させるHTMLファイル


 調べて見るとコンピュータウイルス名として紹介している記事が少ないことに気づきます。 ランサムウェア とかいった形で紹介されるウイルスは多いのですが、昨年はウイルス名がニュース記事には、ならなかったようです。

[あとがき]
 以上については、 Bing からの情報なのですが、気になるのは、やはり、 エモテット です。エモテットは、2014年に登場し、現在も進化し、一昨年から去年まで流行したウイルスです。
 実は、 IPA のホームページでも度々見かけます。この機会にどんなウイルスなのか知っていただき、少しでも世間の セキュリティインシデント を減らすお手伝いができればと考えています。なお、本日は、文章が長くなってしまったので、この辺で・・・。

 では、また!

■ヤバイ「コンピュータウイルス」5選(ナゾロジー)
https://nazology.net/archives/119389

2024年01月04日

HTML 〜プログラミング研究室〜


 こんにちは!
 ナビゲータのEVEです。
hmtl.jpg
 本日は、 HTML の話です。
 以前、お話ししたとおり、2021年1月28日にHTML5が廃止され、現在、 HTML Living Standard に移行しています。ただ、2023年11月30日のブログには、 デファクトスタンダード だったものが、 デジュリスタンダード になっただけなのでは?ット言う話をしています。なお、デジュリスタンダードという言葉を使用しましたが、W3Cは、 民間の非営利団体 です。法的な効力はございませんので、この表現が適当かどうか不明です。
 そんな、HTMLなのですが、HTML2.0から利用しています。

[HTMLを初めて利用したとき]
 私が、HTMLを初めて利用したとき、それは、1996年12月25日でした。

 当時、インターネットは 従量課金 で非常に高価だったのですが、夜中の23時から翌日の7時までは、定額で利用できました。そのため多くの人は、23時以降にインターネットを楽しむのですが、当時、 チャット というのが流行っていて、そこで、全国から集まり話をするのが、習慣となっていました。
 私は、当時からプログラミングはできたのですが、ネットワークとか技術的なことは二の次でした。そのため、当時、サーバーの接続するところから始まって、HTMLをアップロードする方法などに苦労しました。そんな技術的なサポートをしてくれたのが、チャット仲間でした。
 HTMLでホームページを作り、サンタクロースのGIF動画をみんなの協力を得てアップロードできたのは本当に嬉しかったです。それが、HTML2でした。

[HTMLの勉強]
 HTMLですが、 HTMLタグ辞典 を利用しています。
JHTMLタグ辞典1.png
 懐かしいですね!久しぶりに、PDF化した本を見たのですが、 Netscape Navigator3.0 とか Internet Explorer3.0 とか書いてあります。これ、ブラウザですから?Netscape Navigatorなんてい言われてもピンとこない人も近頃は多いのかもしれません。

[HTMLプログラミング時の工夫]
 私が作るサイトでは、以下のような工夫をしています。

?@タグを記述する場合は、必ず一番最初に、開始と終了タグを記述する。
?AHTMLのタグは必ず大文字で記述する。しかし、HTMLの要素については、小文字で記述する。

 ?@ですが、複雑な画面などを作る場合、このルールを守っていないと必ず混乱します。当時からブラウザって、賢く勝手にバグを補正して画面を表示してしまいます。だから、HTML的にバグがあっても、エラーになりません。まっ、それは、それでいいのですが、 JavaScript でプログラミングをしようとした場合、タグをエレメントとして認識しないなどの弊害があります。この点は、実は、メーカー側に改善して欲しいと思っている部分です。そんなに、ごりごりとHTMLを書かない人からすると煩わしいと思うかもしれません。そんな人や私のような人のために、厳格にプログラミングしないモードと、厳格にプログラミングするモードを用意してくれればありがたいのですが・・・。
 ?Aなのですが、これは、私の製造するプログラム限定なようです。私が、よく利用している、「 とほほWWW入門 」でも、作っているページはHTMLすべて小文字で製造しています。実は、大文字で作っているサイトはあまり見かけません。
 HTML的には、大文字、小文字は区別しません。そのため、私の場合は、HTMLのタグとその要素を後で一目で見て分かるように、タグは大文字、要素は小文字と分けて入力しています。
 ただ、少数派であるという事に対して、これから問題にならないか、 ChatGPT にきいてみました。

 HTMLにおいて、大文字でタグや属性を記述することが動作上の問題を引き起こすことは稀です。HTMLは大文字と小文字を区別しないため、ブラウザはどちらの形式でも同様に解釈します。つまり、動作的な違いはありません。
 ただし、小文字で統一することが広く採用されているのは、コーディングスタイルの一貫性と可読性の向上を目的としています。小文字で統一することで、コードの保守性が向上し、他の開発者との協力がしやすくなります。
 将来的な規格の変更や新しい機能の導入に対応する際に、小文字で記述することが推奨される場合もあります。また、特にHTMLの拡張や新しいバージョンでは、小文字での記述が推奨されることがあります。
 総じて言えることは、大文字でHTMLを記述することが動作上の問題を引き起こすことは少ないですが、標準のベストプラクティスに従って小文字で統一することが一般的な開発者の実践です。


 なお、深掘りして、どこの団体が推奨しているのかChatGPTにきいたところ、W3Cだそうです。プログラマとしては、 標準のベストプラクティス が小文字だと言われると、EVEシステムでもそうしなくてはいけない気がしてきます。

[あとがき]
 現在、中小企業診断士試験の方に、かかりっきりの状態なので、もうしばらく、どうするのか考えたいと思います。
 ChatGPTは、可読性が上がるとか言っているけれど、タグと要素の記述をそれぞれ、大文字、小文字とした方が読みやすいと思うのは私だけでしょうか?

 では、また!

■開発体勢の変更 〜システム開発研究室〜(2023年11月30日)
https://fanblogs.jp/bahamuteve/archive/407/0

■とほほのWWW入門
https://www.tohoho-web.com/www.htm

2024年01月02日

ゼロからはじめるシステム開発−今年の抱負− 〜ゼロからはじめるシステム開発〜


 新年あけまして、おめでとうございます。
 ナビゲータのEVEです。
製造.jpg
 昨日は、「 システムエンジニアが目指す中小企業診断士 」から新年のごあいさつと、抱負について書きましたが、本日は、「 ゼロからはじめるシステム開発 」からです。

[今年の各コンテンツの目標]
 今年の各コンテンツの目標は、以下のように考えています。

?@YouTube
 pro2grammer.comで開発したコンテンツの紹介をしたいです!
?ATwitter
 EVE、EVE2のフォローワーの合計を1,000人以上にしたいです。
?BA8
 「ゼロからはじめるシステム開発」、「システムエンジニアが目指す中小企業診断士」、「 システムエンジニアから見た社会 」の合計アクセス平均数が、200人を越えるようにしたいです!

 なんとか、達成したいですね!

[システム開発]
 システム開発は、以下のように考えています。

01月 クラスの製造
02月 クラスの製造
03月 Yahooダウンロード処理の製造
04月 クローニングデータ抽出条件登録・修正・削除処理の製造
05月 Yahooデータ抽出処理の製造
06月 クラス関連の見直し
07月 クラス関連の見直し
08月 ユーザ管理システムの製造
09月 権限管理システム製造
10月 メッセージ管理システムの製造
11月 パラメータ管理システムの製造
12月 コンテンツ管理システム

製造したい、またはしなければならない順番で並べると、以上のような感じになります。 まず、Yahooクローニング関連システムのクラスを製造して、 Yahooクローニングシステム を製造します。
 当初話していたとおり、機能毎にプログラムを分割し、 後日いろいろなサイトのクローニングが容易になるようにシステムを製造します
 6、7月には、運用を開始するのですが、開始後システムの問題点を抽出し、クラスの見直しを2ヶ月かけて実施する予定です。
 そして、8月からは、 ログイン に必要な権限、メッセージ、パラメータ、コンテンツを管理するシステムを製造し、2025年からログインシステムを製造するという流れで考えています。
 製造状況については、適時報告し、最終的な報告は今年の年末に御報告致します。

[あとがき]
 昨年は、年初にたてた目標の多くが達成できました。今年はどうでしょうか?

 今までのやり方を見直しながら、プロジェクトを健全な形で運営できようにがんばります!

 では、また!

Mobilize your Site
スマートフォン版を閲覧 | PC版を閲覧
Share by: