IT Security -既知の脅威と未知の脅威-
東京オリンピック開催まで１ヵ月を切りました。
著者は当選したチケットをまだ持っているのですが、7/6の抽選結果発表が7/10に延期されました。
まだ見られるかどうかが分からずヤキモキしています。
Covid-19による影響は、１年以上経ってもまだ、我々の日常生活を狂わせてしまってます。
では本題のIT Securityの話に入らせていただきます。
■Hashについて
コンピュータ上の実行ファイル、テキストファイルの一意性を確認するためにHashが用いられる
Hashが同じだから必ず一意であることを証明できる訳ではないが、Hashの長さにより一定の一意性は確保できる
ご存じのかたには当たり前の内容であるが、既知の脅威と未知の脅威を説明するために理解いただく必要がある
私のデスクトップ上に VBA.txt というファイルがあるので、これを使って Hash を説明する
Windows 10 端末であれば PowerShell のget-filehash コマンドを使ってHash を求めることができる
|
PS C:\Users\niiven\Desktop> get-filehash .\VBA.txt
Algorithm Hash Path --------- ---- ---- SHA256 13DC1EA6AB2AA9096AA693BDC0B5E93B8A306FDD7508DF48A9C7D89117EAEADD C:\Users\niiven\Desktop\VBA.txt |
VBA.txt を copy して、VBB.txt を作り Hash を求める
|
PS C:\Users\niiven\Desktop> cp .\VBA.txt VBB.txt PS C:\Users\niiven\Desktop> get-filehash .\VBB.txt
Algorithm Hash Path --------- ---- ---- SHA256 13DC1EA6AB2AA9096AA693BDC0B5E93B8A306FDD7508DF48A9C7D89117EAEADD C:\Users\niiven\Desktop\VBb.txt |
ファイル名が変わってもファイルの中身が同じであれば、Hash は同じになる
次にVBA.txtにスペースを１文字追加して Hash を求める
|
PS C:\Users\niiven\Desktop> get-filehash .\VBA.txt
Algorithm Hash Path --------- ---- ---- SHA256 5349551B4E24DED5143C7AE5A851F8419BCEB4D94A84CDC4B1E9289810B47C4F C:\Users\niiven\Desktop\VBA.txt |
ファイルを１文字でも書き換えると Hash は異なるものになる
この Hash は昔からデジタル著名、メールの改竄防止、download したリソースが正しいことを判断するために用いられている。
またセキュリティ製品では、Anti virus製品やIDS、IPSでマルウェア等の検出に用いられる。
Hash による脅威をまとめたサイトはこちら
VirusTotal https://www.virustotal.com/
■既知の脅威
Hash の説明でお伝えしたいことは３つ
・Hash はAnti virus製品や IDS、IPS などで既知の脅威を検知・抑止するために使われている
・ファイル名を変えても Hash は変わらないので、脅威の検知に一定の有効性が認められる
・新たな脅威として認定されたファイルは Hash として広く公開され、再利用されている
しかしながら、ファイルに少しでも変更が加えられると Hash が変わり検知が出来なくなる
これは昨今用いられるスクリプトを使った攻撃では Hash での検知が役に立たないことを意味する
ただし、Hash が全く役に立たないということを意味していない
・IDPSは Hash だけを見ている訳ではない
・未知の攻撃と言われるものも、既知のツールと組み合わせて使うものがある
■未知の脅威への対応
既に Hash 技術だけで全ての脅威からIT資産を守ることができないことは今や誰もが理解されている
境界型セキュリティや既存のAnti Virus製品だけでは守れないことが分かっているので、攻撃を受けてしまったときに対処ができるよう備える必要がある
ここで出てくるのが、ゼロトラストセキュリティモデルである
全ての通信に認証と認可を与えつつ、同時に絶えず監視を行うことが必要となる
具体的なソリューションとしては大きく３つ
- EDR製品による未知の脅威の検出
攻撃の痕跡（IOC）を利用した端末の動作を監視する製品を利用して未知の脅威に対応する方法がある
・VMware Carbon Black Cloud Enterprise EDR (以下CBC EEDRと記載) での例
・ファイルの変更
・ネットワークアクセス
・Registoryの変更
・その他
・CBC EEDRは端末上で実行した全てのイベントを収集・アップロードするので、コンソールで IOC を検索することにより、Hash 登録されていないファイル＝未知の脅威であっても検知が出来る
- NDR製品による未知の脅威の検出
ネットワーク上で脅威を検出する仕組み
全てのノードにEDRを組み込むことにハードルが伴うケースでは、ネットワークで脅威を検出することが手っ取り早い
NDRを唄う製品の多くはIDPSカテゴリに類する製品であるが、前出のシグネチャ以外にもネットワークプロトコルでの検知を行うため、EDR製品ではカバーできない領域の検知を行うことができる
また、検体をサンドボックスに上げて動作を見る製品もあり、より厳格な脅威の検知を行うことができる
ただし、ネットワーク上ではSSL/TLS, SSHなどの暗号化されたパケットの中身を見ることができないため、EDR製品とNDR製品の利用箇所、カバー領域を考えて、適切な利用に努めることが重要になってくる
- SIEM/SOARによるロギング、検知と対処
単一の製品でロギング、検知を行うことは出来る仕組みを持つが、複数製品を組み合わせた場合にはそれぞれの製品コンソールだけでは相関関係が分かりにくく、製品の数だけコンソールを見なければならない
２-３製品であれば出来なくもないが、それぞれの製品に過検知、誤検知があり得ることを考えると、運用者の負担が大きくなりすぎてくる
EDR, NDR 製品は標準設定において過検知をすることがあるので挿入直後において抑止設定を行うことは殆どない。このため検知のみでそのアラートを見ることがないようでは、製品導入した意味がなくなってしまう
これらの情報を１箇所に集め、総合的に判断を行うツールがSIEMであり、さらにその対処まで行うものがSOARと呼ばれる
- まとめ
・EDR, NDR, SIEM/SOAR を組み合わせることで、既知の脅威だけでなく、未知の脅威にも対処することができる
・各製品でできること、できないことを理解して、適切な個所に適切な製品を配置する
今日はここまでです。
最後まで読んでいただきありがとうございました。
Load Balancer -DSR and IP address translation (SNAT)
I often asked Load Balancer (LB) and Source Network Address Translation(SNAT), I will write the answer and let them seeing this article in next time.
1. Direct Server Return (DSR) by LB
DSR is a function of LB to increase the availability of application throughput, such as video distribution services.
DSR compatible LB is a prerequisite. Big5 or Citrix NetScaler are capable for DSR.
Let me explain packet flow.
Client requests LB ①, LB forwards backend server ➁, and backend server replies directly to client ➂.
|
|
Source IP |
Destination IP |
|
① |
Client IP |
VIP of LB |
|
➁ |
Client IP |
Backend server IP |
|
➂ |
Backend server IP |
Client IP |
The point is backend server does not send back the request to LB.
LB just passes only the client request, it reduces process on LB, does not become a bottleneck.
LB does not change source IP address, forwards to backend server in ➁.
It performes asymmetric routing, if the Layer3 switch (L3SW) manages TCP session control, drops the reply packet. You must configure L3SW not to manage the sessions.
2. Source NAT on LB (Not DSR)
The case backend server records the source IP address, SNAT does not required on LB.
LB located inline, it can perform easily.
But LB has 1-armed and LB does not support DSR, leads complicated design.
I meant say it does not realize, but you had better consider following options.
- Client IP logging options
- Logging on LB
- LB is able to logging client IP.
- X-Forwarded-for header
- LB adds client IP information on XFF header.
If your stakeholder does not allow the options above, I recommend the following design.
|
|
Source IP |
Destination IP |
|
① |
Client IP |
VIP of LB |
|
➁ |
Client IP |
Backend server IP |
|
➂ |
Backend server IP |
Client IP |
|
④ |
VIP of LB |
Client IP |
Backend servers should reply to LB VIP in ➂, their default gateway must be LB VIP address.
If backend servers should access NTP server, logging server or MTA on different subnet, add static route for them. It might be a L3SW address.
日本語はここから
Load Balancer (以下LB) と SNATに関する質問をいただいたので、こちらにメモします。
NSX Datacenter for vSphere がDSRに対応していないため、この質問は何年も前からよくいただいています。
１．DSR (Direct Server Return)とは
動画配信サービスなど、高いスループットを必要とするアプリケーションの可用性を高めるための LBの一機能。
Client (端末) からのリクエストは LB を経由してバックエンドのサーバに送られます。
バックエンドのサーバはこれを LB に戻すことなく、直接 Gateway に戻ｓｙ。
戻りのパケットは LB を経由しないため、LB の処理が少なくなり、オーバーヘッドを減らせるのがメリット。
LB は自分にパケットが戻らないように送信元IPアドレス (端末のIP)を付け替えずにバックエンドのサーバにパケットを送ります。
Gateway より先では、非対称のルーティングを行うことになるので、セッションを管理する機器があるとこれを落とす (破棄する) ことになるのが留意事項となります。
またNSX-vのLBなど、DSRに対応していないLBのもあるので、この点に留意します。
２．LBのIPアドレス変換（Source IP Network Address Translation, 以下 SNATと記載）
バックエンドのサーバが送信元のIPアドレスを記録するため、LB でのSNAT を行わないで欲しい（Client IPを保持したままバックエンドサーバに送りたい）というケースがあります。
構成パターンとしては、インライン (2-armed) のケースではほとんど問題にならないのですが、1-armedでは少し複雑な構成となります。
1-armed, SNAT有とした場合の代替手段として、LB で X-Forwarded-For (以下XFF) の HTTP ヘッダを挿入することで、 LB の SNAT を行っても、Souce IP (端末のIP) を知ることはできます。
バックエンドのサーバが XFF に対応していることが前提条件ですが、それほど難しいことはなさそうです。
こちらのリンクを拝見しましたが、Apache ではLogFormatに"%{X-Forwarded-For}i"を入れるだけのようです。
<https://www.suzu6.net/posts/244-apache-log-x-forwarded-for/>
1-armed, SNAT無とした場合、バックエンドサーバからClient IP宛のパケットをLB VIPに戻すために、バックエンドサーバのDefault GWをLB VIPにします。
また、バックエンドサーバは自らが提供するサービスだけでなく、クライアントとしてMTAやNTPサーバなどにアクセスする必要があるので、これらに対応するためスタティックルートを設定する必要があります。
これを忘れるとバックエンドサーバから別セグメントへの通信ができません。
稀に社内イントラ向けのバックエンドサーバではClient IPレンジが決まっているというケースもあるので、その場合はClient IPレンジのGatewayをLB VIPとしてスタティックルートに設定することもあります。
この場合はDefault GWとしてLayer3スイッチのアドレスを設定します。
以上となります。
最後まで読んでいただきありがとうございました。
VM Migration with HCX + PowerCLI
日本語は下のほうに
Congratulation!
Yuta Watanabe, NBA player, contracted Toronto Raptors in April 19.
https://www.nba.com/raptors/raptors-sign-watanabe-standard-nba-contract
He continued his tireless efforts grabbed a standard contract.
Let me introduce VM migrations @VMC on AWS.
I have engaged VMC on AWS service for 2 years.
VMC on AWS does not have to design, just deploy and consume it.
But customer have to design connecting on premise and VMC, and VM migration.
I have to tell VMC on AWS environment. Mostly network connection for them.
And how to migrate VMs from on premise to VMC on AWS.
I mean design element still remains on VMC.
I propose HCX for customer having on premise and VMC environment.
HCX is powerful tool not only extend Layer2 but for VM migration.
I would like to refer VM migration with HCX in this article.
Customer select cold, bulk, vMotion and Replication-Assisted vMotion(RAV) for their VM migration with HCX 4.0.
They can migrate easily from HCX GUI.
If they have more than 100 VMs, it is hard to migrate without any mistake in a certain period.
We recommend using PowerCLI in the case.
Anyone can use PowerCLI for HCX migration.
Please see following links.
https://vmusketeers.com/2020/01/06/hcx-powercli-scripts/
I confirmed it on PowerCLI 12.3, SDDC 1.14, HCX 4.0.1 and vSphere7 environment.
It worked.
RAV is new migration type on VMC on AWS.
You can select RAV with "-migrationType RAV".
VMC uses vSAN for the storage, you need add "-DiskProvisionType Thin".
RAV migration requires "-ScheduleStartTime" and "-ScheduleEndTime".
Let me show on my lab experience.
> Connect-HCXServer -server hcx01.corp.local -user administrator@xxxx -Password XXXXXX -force
Server User
------ ----
hcx01.corp.local administrator@vsphere.local
You also have to connect HCX@VMC on AWS.
> get-hcxvm
Name PowerState Id
---- ---------- --
yVM3 PoweredOn vm-20032
yVM4 PoweredOn vm-26001
yVM5 PoweredOn vm-26002
> Get-HCXNetwork
Name Type Id
---- ---- --
mgmt-app-network OpaqueNetwork network-o23
VMOTION OpaqueNetwork network-o28
sddc-cgw-network-1 OpaqueNetwork network-o29
mgmt-ls OpaqueNetwork network-o30
VSAN OpaqueNetwork network-o35
direct-connect-ls OpaqueNetwork network-o34
L2E_VM_Network22-RP2-22-94f187f3-1473668478 OpaqueNetwork network-o1050
L2E_VM_Network22-RP2-22-94f187f3-1473668478 NsxtSegment /infra/tier-...
MA-VMW-VMotion Network network-1039
DistributedVirtualPortgroup dvportgroup-...
vMotion1 DistributedVirtualPortgroup dvportgroup-...
VM Network22-RP2 DistributedVirtualPortgroup dvportgroup-...
<SNIP>
VM Migration
Syntax
Get-HCXMigration [-EntityId <String>] [-MigrationType {vMotion | Bulk | Cold | RAV | OsAssistedMigration}] [-NumberOfMigration <Int32>] [-Server <HcxServer>] [-State {MIGRATED | MIGRATE_CANCELED | MIGRATE_FAILED | MIGRATING}] [-Username <String>] [<CommonParameters>]
Syntax
Start-HCXMigration [-Migration] <HCXMigration> [-Confirm] [-Server <HcxServer[]>] [-WhatIf] [<CommonParameters>]
日本語はここから
渡辺雄太さんがトロントラプターズとの本契約を勝ち取りました。
おめでとうございます。
ディフェンス、リバウンド、3ptには定評がありましたが、最近のプレーではドリブルでのペネトレートからのシュート、パスが冴えわたってきています。
トロントは2019年にも優勝したチームであり、選手層が厚いために彼は短い時間の出場となっていますが、その中で成果を出し続けてきたことへの評価だと思います。
このサイトを読んでジーンときてしまいました。
https://www.theplayerstribune.com/jp/posts/basketball-nba-Yuta-watanabe-raptors-kotobanochikara
さて、本題のHCXは、Cold, Bulk, vMotion, RAV と、多くの移行パターンが選べるようになって、HCX 4.0はさらに使い易くなっています。
HCX + PowerCLIですが、リンク先のmuketeerのサイトにもある通り、完動します。
GUIからでも勿論移行は出来ましたが、設定すべきオプションが多いので、移行台数が多いケースではPowerCLIをお薦めします。
CSVファイルから読み込む形にすれば、さらに操作は容易になるでしょう。
最後まで読んでいただき、ありがとうございました。
東日本大震災から１０年経とうとしています
１０年前のあの日のことは一生忘れられない。
あの日の話は体験した人それぞれで違うものであるが、いつもとは違う非日常であり、仲間やお客様、様々なかたとそれぞれの体験を話すことが時折ある。
あの体験を文章に興すのは初めてであるが、１０年経って今覚えていることを書き留めておきたい。
3/11の午後、客先との打合せを終え、帰社途中に震災に遭遇した。
地下鉄に乗ってつり革を持ちながら立っていたのだが、急ブレーキが掛かり電車が停止した。最初は何が起きたのか分からなかったが、車内アナウンスで大きな地震があったことを知った。
停車している間にあった３回ほどの余震で、かなり大きな地震だったことが分かった。
（小規模の地震で余震を伴うことは稀である）
しばらくして電車は次の停車駅まで徐行運転し、大手町駅に着いた。
駅につくと、またアナウンスが流れた。
「現在地下鉄、JR含む、全ての電車が止まっております。この電車もいつ頃動くか分かりません」
乗り換えも出来ないのか。それではしばらく待つかと思い、空いた座席に座ってから会社にメールした後、自宅に電話した。
当時Willcomを使っていたので、震災時にも通信制限がかかっていないことが幸いした。（他の携帯会社は制限がかかっていたので、通話はできなかったらしい。）
子供たちは皆自宅に戻り、昼寝していると聞いて安心した。
しばらくすると、駅のアナウンスが流れた。
「現在大津波警報が出ています。駅構内のお客様はすぐに避難をして下さい」
大津波ってどういうこと？と思い、地下鉄の駅から地上に上がることを決意して駅を降りた。海水が駅構内に流れてこないことを祈りつつ、後ろを歩く人がパニックになることのないよう走ったりせず、階段を足早に登っていくと地上に出た。
足元見ても水は無かった。
東京には津波は来ていなかったと分かって少しだけ安心した。
曇り空の下、多くの人がパニックになることなく歩いていたので、また安心した。ヘルメットを被っているスーツ姿の人も何人かおられた。
市原の自宅まで歩くのは土台無理なので、そちら方面の電車がある秋葉原に行って、ついたら型落ちのマザーボードを探してみようと思い、秋葉原まで歩いた。しばらくして電車が動き出したらそれに乗って帰ろうと考えた。
この時点では全く状況を把握できていなかった。
秋葉原の家電量販店に入ったものの、マザーボードは欲しいものが在庫には無かった。久しぶりの秋葉原なので、他にも何か買おうかなとも思ったが、電車が動かないとなると荷物が面倒になるので買い物は取り止めた。
量販店から出ようとしたとき、TV販売コーナーで東北地方の港の津波映像が流れていた。見たことのない大波で、人の乗っていない漁船が、うねりに任せて上下左右していた。港を見下ろす高い位置からの映像だったが、固定カメラではなさそうなので、撮影しているカメラマンが大丈夫なのか心配になった。
えらいことになったな。
この津波では助からない人も出てくるだろう。
震源は東京近くではなく、遠く離れた東北の地震でこれだけ揺れるとは。
想像してたより相当酷い。
現実を振り返ると１人になった自分自身のことを考えなければならない。
ホテルに泊まるとしても、タクシーに乗るとしても、役に立つのはキャッシュである。
まずは現金を下ろすことにした。
地震の影響でキャッシュディスペンサーが使えないことを心配したが、いつも通りに現金を下ろすことができた。少し多めの額を引き出した。
懐が温まり、１つ心配事が消えた。
銀行で携帯を見ると会社からのメールが返ってきていた。
会社には戻らずに各自安全に帰宅せよとのこと。
秋葉原駅に向かうと、人がごった返しており、駅構内に入ることができなかった。駅入口にも辿り着けなかった。
メガフォンマイクを持った駅員さんのアナウンスを聞くと、本日中に電車が動き出す可能性は低そうだった。
今から急げばホテルに宿泊もできるだろうが、まだ明るいので、歩けるところまで歩こう。
自宅の市原までの徒歩（約60km）は無理なので、まずは市川(約25km)の実家を目指そう。
今履いている革底の靴は長距離を歩くのには不便であること、長距離歩くには自転車のほうが楽で速いことが頭に浮かんだ。
２つを手に入れられたらそうしようと思い、靴屋、そして、自転車屋を探しながら、実家近くを通る蔵前橋通りを目指した。
早速、浅草橋駅の近くにゴム底の靴屋を見つけ１５００円の歩きやすそうな靴を購入し、履き換えた。革底の靴はかさばったが、これ位の荷物なら持ち歩けないことは無い。そして、長距離歩くための準備は整った。
次に蔵前橋通りで自転車屋を見つけたが、自転車は売り切れていた。
皆考えることは同じなので、売り切れてしまうのは当たり前なのだが、少しがっかりした。
しばらく歩くと、また、自転車屋があった。
そこで自転車は残っていないか聞くと、１台だけ中古の折り畳み自転車があるという。
車輪が20cmほどのこぎ難そうなもので3万円弱というが、背に腹は変えられない。残り１台。他にはない。
３秒考えて購入することとした。自転車に乗って市川を目指せば、徒歩よりも少しは楽になる。
蔵前橋通りはひどく混雑していて、車は全く動けないほど渋滞していたが、自転車は車の間を抜けていけるので、原付バイク並に速く進むことができる。
車輪の小さな折り畳み自転車ではあるが、実際、自転車より少し幅の広い原付は車間のすり抜けが難しい箇所で停車せざるを得ないため、自転車のほうが速いときもあった。
車でしか通ったことのない道や橋を自転車から眺めると、今までとは違った風景に見えた。
３月はまだ暖かい季節とは言えず、日中は暖かさもあったものの、日暮れとともに寒くなってきた。
東京から千葉方面に歩く人が次第に多くなってきた。逆方向に歩く人は皆無だった。
歩道を歩いて帰宅する人を見ながら、渋滞した自動車車線の隙間を走り、実家まで駆け抜けた。
ちょうど19:30に市川の実家に着いた。
実家の親も元気で怪我もない様子。
（後から聞いた話では、東京駅近辺から歩いて帰った近所のかたは、23時過ぎにようやく帰宅したらしい。）
シャワーを浴びた後、TVニュースを見て今日の災害を知ることとなった。
北日本の沿岸は全て津波警報が出されたままで、耳につく警報と共に各地の被害状況がレポートされていた。津波にさらわれた木材が燃えている映像を見て、流された方々が生きて戻れるのかどうかとても気になった。
各地で数十名単位の死者数がTVに映っているのをただ呆然と眺めていた。
How to use OWASP ZAP
- Open ZAP
- “Do you persist the ZAP Session?” → No
- Select “Protected mode”
- Proxy setting for ZAP and Browser.
ZAP : Tools > Option
Firefox : Option > Network Settings > Settings
- Select “Manual explore” and Launch browser.
- Include context
Icon marked
- Delete unused sites
- Start spider scan
Duration depends on environment, it will take more than 10 minutes.
- Completed Spider, start dynamic scan.
You can see progress chart. It will take more than 1 hour. 
- Get the report of result.
You can get the results now.
<EOF>
昨年末 Winter Cup 2020（高校バスケットボール全国大会）に行ってきた話
コロナ禍の中、Winter Cupが行われました。
今年の高校３年生は、インターハイ、国体が中止となったため、唯一の全国大会でした。
この状況下で大会を開催するのはとてもたいへんだったと思います。本当に開催主催者、関係者に感謝します。
このために３年間頑張ってきた選手にとってはとても有難い大会だったと思います。
ただ、大会前に選手が感染してしまったり、大会中に部の関係者に発熱があったりして、棄権せざるを得ない学校も出てしまい、涙を飲んだ子もいました。とても残念だったでしょう。
会場には教諭や同級生などの学校関係者、生徒の父兄のみ入れましたが、当該試合の開始前に入場、試合が終わったら即退場するため、過去の大会と異なり応援がとても少なかった。
他の試合も見たかったけど、今年の感染状況を考えると仕方がない。
今回の大会で改めて感じたのは、日本のコロナの検査体制が弱いこと。
選手や関係者に対して大会前、大会中にPCR検査を行うことができれば、不本意な棄権を避けることができたはずです。
年末年始には１日の日本国内感染者が5000人を超える状況ですが、実際にはもっと多くの感染者がいるはずです。
緊急事態宣言期間が始まりますが、検査体制の拡充を行ってほしい。
このままの体制では、自分自身が感染しているかどうかも分からないままに感染を拡大させてしまう状況が続いてしまわないか、とっても心配です。
学習者用デジタル教科書の制度化
先日の続きになります。
紙媒体の教科書を電子化するだけでは面白くない。
いくつかの追加の提案を行いたい
１．インターネットアクセス
学習者用デジタル教科書のイメージ
＞デジタル教材との一体的使用 （例）動画・アニメーション、ドリル・ワーク、参考資料
電子化することにより動画が見られるのは当たり前のことだ。
Internet, Intranet上の動画を見られるようになる。学習に動画が役立つものもたくさんあるだろう。
端末からInternetに接続するには、教育的見地から暴力やポルノ、ゲームなどのサイトを除外すべきである。
端末にProxyを経由する設定を行い、そこでフィルター設定をすることで、見ることのできるサイトを絞ることが必要になる。
もちろん１台のProxyで行うには限界があるし、各都道府県でサイトを設定するのは無駄なので、１箇所で共通設定を行い、Proxyの分散処理ができる仕組みを取り入れればよい。難しいことではない。
２．教室での学習環境の整備
電子化する対処を教科書に留めるのはもったいない。
まず、黒板を半分にして、もう半分をプロジェクター、或いはホワイトボードで書込み可能な液晶画面にして、教諭の黒板へ書く時間を減らしたい。
自分自身、高校数学では教諭が数式を書いては消すだけのものであり、実りの無いものだったことからも、投影で済ませられるものであればそうすればよい。
生徒の理解を１番に考えるのであれば、自ずとそうなるはずである。
学校教育は年度毎にほぼ同じ資料を使うものが多く、クラス毎に同じコンテンツを利用するのであれば１度作った電子資料は効率的に再利用が可能なはずだ。
小テストや書込みのため、授業に紙媒体を使うこともあるのでプリンタも必要になる。
教室にはWifi、Pad用の充電装置が必要となるので、電子機器を扱うための教諭向けの研修を行う。
３．教科書を共有化、パブリックドメイン化する
教科書は生徒が見るだけのものではなく、親も見ることが出来るようにすべきではないだろうか。
そして学校には教育のプロである教諭がたがおられ、生徒の理解をより深いものにするために補助資料を作られている教諭も多い。
教科書があるために補助資料という形式を取っているのであろうが、そういった教諭には、教科書を作る能力は持っている。
であれば、教科書を書籍会社で作る必要はなく、教育者が作ったほうがよいと考える。
教科書検定も必要なプロセスの１つとすれば、検定を行う方々にレビューする側ではなく、作る側としても活躍して欲しい。
そして、作った教科書をPublicDomain化して、自由にアクセスできるものにすればよいであろう。
電子化するだけでなく、教科書を作るところから教育者が行うことができれば、教科書予算の削減にもつながることは確実だ。
教諭が無償で教科書を作ればよいと言っているのではないことに留意されたい。
４．閲覧履歴を学習に活かす
電子化することにより、インターネットアクセス履歴だけでなく、生徒１人１人が教科書のどのページを閲覧したことのログが取れる。
特に理解が良くない子については、閲覧履歴から理解できていない点を把握することにも役立つはずだ。
